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Sir: 

This Reply Brief \s filed pursuant to 37 C.F.R. § 41.41 in response to the Examiner's 
Answer mailed April 28, 2009. A request for oral hearing was previously submitted on Nov. 1 7, 



Pages 1-15 of the Examiner's Answer repeat the rejections in the final Office Action, and 
were fully addressed in Appellant's Appeal Brief filed August 12, 2006. This Reply Brief 
addresses the "Response to Argument" beginning on page 16 of the Examiner's Answer. 

The primary reference cited in the rejections is U.S. Pat. Appl. Publ. No. 2002/0142757 
to Leung et al. ("Leung"). The examiner is correct insofar as the reference was misidentified in 
Appellant's Appeal Brief in the headers. However, Appellant's arguments remain valid, and the 
proper citation to Leung is provided in the remarks therein. 

The Final Office Action mailed October 18, 2005 (hereinafter referred to as Office 
Action), rejects claims 1-4, 9, 10, 12-15, 18, 19, 23-26, 29, 30, 34, 37-40, 43, and 47 under 35 
U.S.C. § 102(e) as allegedly anticipated by Leung, Leung was filed August 20, 2001, claiming 
priority to provisional application 60/279,970, filed March 28, 2001. The Examiner's Answer 
raises a new ground of rejection of the claims, namely, reliance on paragraphs [0087]-[0089] of 



2006. 
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Leung. Prior to the Examiner's Answer, the Office had not relied on paragraphs [0087]-[0089] of 
Leung. Applicants therefore provide an attached Evidence Appendix pursuant to 37 C.F.R. 
§ 41.37(c)(l)(ix) in support of the responsive argument presented below. 

On June 2, 2004, Appellants submitted a Declaration Under 37 C.F.R. § 1.131, establishing 
a date of invention prior to October 1 1, 2001. 1 On October 1, 2004, Appellants submitted a Second 
Declaration Under 37 C.F.R. § 1.131, establishing a date of invention prior to August 20, 2001. 2 
Thereafter, the examiner dropped the rejections then pending, evidently accepting that the 
declaration was effective. Leung was filed on August 20, 2001, and is therefore valid as a reference 
only insofar as it is supported by the provisional application filed March 28, 2001, i.e., Leung 
paragraphs [0087]-[0089] are only prior art if they are supported by the provisional application. 
Without conceding whether or not the Leung published application does or does not anticipate any 
claims, a review of the provisional application reveals a lack of support for the sections of the Leung 
published application cited by the examiner, i.e., there is no support in the provisional application at 
least for paragraphs [0087]-[0089] of the cited Leung reference. Leung therefore does not anticipate 
any claim. 

More specifically, the provisional Leung application does not include any of the parameters 
cited by the examiner. For example, the provisional Leung application does not teach or even 
suggest the parameter NUM_NGHBR or any equivalent; the provisional Leung application does not 
teach or even suggest the parameter FBSCH_SHO_SUPPORTED or its equivalent; the provisional 
Leung application does not teach or even suggest the parameter NGHBR_PN or its equivalent; the 
provisional Leung application does not teach or even suggest the parameter 
NGHBRFBSCHCODECHAN or its equivalent; and the provisional Leung application does not 
teach or even suggest the parameter NGHBR FBSCH CODE CHAN INCL or its equivalent. 

The most relevant portion of the provisional application appears to be section 3.9: Soft 
Handoff, on page 3-20 of the provisional application. As indicated above, section 3.9 does not 
teach or suggest any of the parameters relied upon in the Office Action. Instead, the Leung 
provisional application merely describes a system where multiple sectors operated by the same base 
station synchronously transmit the same information. The provisional Leung application further 

1 A copy of the Declaration and supporting documents is provided in the attached Evidence Appendix. 

2 A copy of the Second Declaration and supporting documents is provided in the attached Evidence Appendix. 
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states that, when a "[mobile station] performs Idle Handoff to a new sector, if the sector is not part 
of the [soft handoff] group of the sector the [mobile station] was previously monitoring, then the 
[mobile station] needs to determine the new [soft handoff] group from the overhead message on this 
new sector" (emphasis added). There are multiple sectors within a given cell. The provisional 
Leung application therefore does not anticipate any independent claim, e.g., because Leung does not 
teach or suggest receiving from a base station corresponding to the first cell, a broadcast message 
communicating multicast session information for a plurality of cells comprising the first cell and 
a second cell 

Section 3.9 of the provisional Leung application is reproduced, in relevant part, below: 



3.9 Soft Handoff 

The goal is to put the high-speed broadcast channel into soft handoff, i.e. the BS involved in SHO 
shall synchronously transmit the same broadcast information on the F-BSCFL The MS shall be able to 
perform autonomous soft handoff. This implies that; 

- BS does not dynamically assign the F-BSCH Active Set to the mobile station (obviously) 

- Overhead messages indicate the list of BS participating in SHO, 

The overhead message transmitted in each sector will list the identities of B3 that are part of the SHO 
group. By SHO group, we mean all BS transmitting the information synchronously. An MS may soft 
combine the transmissions from only the base stations belonging to the same SHO Group. This is 
similar to the SHO group proposed for QPCH SHO and F-CCCH SHO. Although it is desirable to 
have as many BS as possible in each SHO group to increase the effectiveness of SHO, this size may 
be restricted by the network effort required to synchronize the transmissions. 

When the MS performs Idle Handoff to a new sector, if the sector is not part of the SHO group of the 
sector the MS was previously monitoring, thai the MS needs to determine the new SHO group from 
the overhead message on this new sector. But fee MS shall start to monitor the F-BSCH transmission 
from this new sector immediately upon performing Idle Handoff, to avoid any interruption in HSBS 
reception. But the quality of reception during this interval (required to determine new SHO group) 
may be poor. 

Note that the neighbor list messages will indicate whether or not the F-BSCH in the target base 
station has the same configuration as the current F-BSCH; if not, once MS performs the idle handoff, 
MS needs to read the overhead messages to determine the new F-BSCH configuration. 

It was noted that for inter-BSC SHO, one BSC can act as the Master BSC, similar to currently done 
for packet da ta services. 

Appl No. 60/279,970 - Section 3.9, paragraphs 1-5 
Furthermore, even if there were support in the provisional Leung application for the 
provisioning of neighboring sector information, there is no support in either the published Leung 
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application or in the provisional Leung application that the information corresponds to a first and 
second cell, as claimed. Stated differently, Leung (both the provisional and the published 
application) only describe transmission of limited information regarding sector transmissions, 
not for differing cells, as claimed. Indeed, the provisional application distinguishes between 
sectors and cells at page 30 of the presentation slides entitled "Section 2: cdma2000 Overview" 
(approximately page 145 of the provisional application), whereas the neighbor information 
described in section 3.9 is only with respect to different sectors. The relevant portion of page 
145 is reproduced below: 

• Pilot Channel 

- Transmitted Constantly 

- Allows Mobile to Acquire the System 

- Provides Mobile with Signal Strengt h for Comparis on 

- Has Unique PN Offset (2 15 ) for eac ^Tell or Sector^ 

With regards to any given cell, the Leung provisional application is clear that broadcast 
messages carry cell-specific overhead messages: 

Forward Broadcast Channel (F-B£tlX^~ 

• F-BCH is broadcast over the entire cell and carries/^eM specifi^ 
overhead messages previously transmitted on the Paging Pbfmnel 

- IS-95 Overhead messages 

» Systems Parameters Message 
» Extended Systems Parameters Message 
» Extended Neighbor List Message 
» General Neighbor List Message 
» CDMA Channel List Message 
» Extended Access Parameters Message 
» Global Service Redirection Message 

Provisional .Leung Application, p. 221. The fleeting reference to a "Neighbor List" does not 

provide any support for what, if anything, is included within the neighbor list. Leung is therefore 

deficient for this additional reason, i.e., even if Leung does describe transmission of information 

for neighbors, it does so only with respect to neighboring sectors, and not with respect to a first 

and second cell, as claimed. 

Lastly, even if Leung were interpreted as providing information in a first cell for a 

plurality of cells comprising the first and second cells (which Appellant does not concede), there 

is still no teaching or suggestion that such information is multicast session information , as 
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claimed. Even if Leung were interpreted to disclose transmission of the identities of other base 
stations in a SHO group (see Appl. No. 60/279,970 - Section 3.9, paragraph 2, above) as 
information for a plurality of cells as claimed, the identities of other base states are not the same 
as the claimed multicast session information. The claims are therefore allowable over Leung for 
this additional reason. 

Appellants believe that the above reasoning presents the clearest arguments for 
overturning the rejections in this case. For all the foregoing reasons, and based on the previously 
submitted arguments, Appellants respectfully request that the Board instruct the examining corps 
to withdraw the rejections and pass this case to issuance at its earliest convenience. If there are 
any questions or any additional information is required, please contact Appellant's undersigned 
representative at (202) 824-3153. 

Respectfully submitted, 
BANNER & WITCOFF, LTD. 

Date: June 22, 2009 By: /Ross Dannenberg/ 

Ross A. Dannenberg 

Registration No. 49,024 

1 100 13 th Street, N.W., Suite 1200 

Washington, D.C. 20005 

Tel: (202) 824-3000 

Fax: (202) 824-3001 
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Evidence Appendix 

37 C.F.R. §41.37(c)(l)(ix) 

Exhibit 1: Declaration Under 37 C.F.R. § 1.131 submitted June 2, 2004, and 

supporting documents. 

Exhibit 2: Declaration Under 37 C.F.R. § 1.131 submitted October 4, 2004, and 

supporting document. 



RECEIVED 

OCT 0 8 2004 

technology Center 2600 

ID TRADEMARK OFFICE 

Atty. Docket No. : 004770.00026 

Group Art Unit: 2682 
Examiner: West, Lewis G. 

Confirmation No.: 8406 

SECOND DECLARATION UNDER 37 C.F.R S 1.131 

The Honorable Assistant Commissioner for Patents 
Washington, D.C. 20231 

Sir: 

We, Toni Paila (Finnish), Jani Poikela (Finnish), Lin Xu (Chinese), Juha-Pekka Luoma 
(Finnish), and Rod Walsh (British), hereby declare that: 

1) We are the joint inventors of the above-captioned application, which is generally 
directed to Advanced Service Announcement for Broadcasting (ASAB); 

2) Prior to August 20, 2001, the filing date of U.S. Patent No. 6,731,936 B2 
(hereinafter "Chen"), we conceived of the invention recited in claims 1-47 of the 
above-captioned application, at least to the extent the claims are allegedly taught 
by Chen, and diligently pursued constructive reduction to practice in the form of a 
patent application filed with the United States Patent & Trademark Office. 

3) Prior to August 20, 2001, we developed a protocol specification for Advanced 
Service Announcement for Broadcasting (ASAB), a version of which is attached 
as Exhibit A. 

4) Correspondence at least as early as June 6, 2001 included a copy of the ASAB 
Protocol Specifications (see Exhibit B). 



wrff tj\ IN THE UNITED STATES PATENT AI 



* In re the Application of: 

S %r i x*!0y Toni Paila et al. 



Serial No.: 09/988,241 

Filed: November 19, 2001 

For: MULTICAST SESSION HANDOVER 



Serial No. 09/98W41 - 2 - Atty. Dkt. No. 004770.00026 

5) Concurrent to creating the ASAB Protocol Specifications, and also prior to 
August 20, 2001, we developed ASAB Server Side Specifications, a version of 
which is attached as Exhibit C. 

6) Correspondence at least as early as July 30, 2001 included a copy of the ASAB 
Server Side Specifications (see Exhibit D). 

7) Upon substantial completion of the specification documents attached as Exhibits 
A and C, we continued work on the development of ASAB, and prepared a 
disclosure document of an embodiment of the invention (Exhibit E). The 
disclosure document was submitted to the Nokia Internal Patent Committee at 
least as early as September 4, 2001, as evidenced in Exhibit E. 

8) The Internal Patent Committee evaluates and processes received invention reports 
on a first come-first serve basis After receiving an invention report, the Internal 
Patent Committee performs a patent search for relevant prior art in order to 
facilitate the patent filing decision. If a decision is made to proceed with the 
preparation of a patent application based on the invention report, the invention is 
assigned a rating from 0 to 5 based on the potential value of a resulting patent, 
and an instruction letter is sent to an outside counsel, with the invention report, 
requesting preparation of a patent application for the invention. 

9) After its in-turn review and analysis by the Internal Patents Committee, the 
disclosure document attached as Exhibit E was sent to our patent attorney, Mr. 
Bradley C. Wright of the law firm Banner & Witcoff, Ltd., on October 1 , 2001 , as 
evidenced by the email communication attached as Exhibit F. 
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10) On October 30, 2001, Ross Dannenberg (also an attorney with Banner & Witcoff, 
Ltd.) sent a draft of the above-captioned patent application to our employer for 
our review. A copy of the email communicating the draft is attached as Exhibit 
G. 

11) On November 13, 2001 Ross Dannenberg sent a revised draft of the above- 
captioned patent application. A copy of the email communicating the revised 
draft is attached as Exhibit H. 

12) On November 19, 2001, the above-captioned patent application was filed in the 
U.S. Patent and Trademark Office. 

13) The exchange of draft applications with our patent attorney demonstrates 
diligence from before August 20, 2001 until the filing of the above-captioned 
patent application and the constructive reduction to practice of our invention. 

14) All acts referred to in this Declaration were performed either in the United States, 
or in a WTO member country; 

15) The attached Exhibits have not been altered since they were originally submitted 
to the Patent Committee or otherwise prepared or communicated; and 

16) We declare under penalty of perjury under the law of the United States of 
America that statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be true; and further that 
these statements were made with the knowledge that willful false statements and 
the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Title 18 of the United States Code and that such willful false statements 
may jeopardize the validity of the application or any patent issuing thereon. 
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1. INTRODUCTION 

This is a protocol specification extending the basic SDP. This document is result of ASAB 
project and, thus the requirements for extensions come from the requirements of ASAB. 

The purpose of this document is to extend SDP beyond its current use in two ways. First, 
this means that use SDP to describe services instead of plain multicast sessions. A 
multicast sessions thus becomes a simple basic service. An example of another services 
that we want to describe is unicast connectivity. In addition, we consider several new 
parameters that are needed when services are announced in broadcast network. 

Second, we extend the SDP to be able to express celMevel mappings. This means, that 
there will be special annoucements that actually describe mappings between IP addresses 
and cetl-paramenters. Thus, these announcements do not descrbe a specific "session". 

This document is structured as follows. 

• In chapter 3, we give two sets of requirements that are needed, but which the current 
SDP does not fulfil. 

• In chapter 4, we describe the extensions to the basic SDP protocol to support new 
session-level attributes. The specification follows the principles of SDP specification. 
Thus we use ABNF together with a set of examples. 

• In chapters, we extend the SDPfutherto cover the special mappings. The specification 
follows the principles of SDP specification. Thus we use ABNF together with a set of 
examples. 
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3. REQUIREMENTS FOR SERVICE DESCRIPTION PROTOCOL 

In this chapter we list and explain the requirements for the service description protocol. The 
base protocol for service descriptions was chosen to be SDP [1]. Thus this means, what 
kind of information we need to be able to express with SDP and how to extend it. The 
requirements listed in this chapter originate from ASAB requirement specification [2J. 

We have iterated, refined and categorised the requirements. There are two basic 
categories of requrements: session-level attributes and special mappings. The session- 
level attributes enhance the expression power of an single service announcement. The 
following is a set of requirements in that category 

1 . What is the cost of the service? Not all the services are freely accesible. Thus, it is 
necessary to be able to express the cost, cost mode and currency related to the service 

2. What is ttie availability and status of a service? The basic SDP expects that the 
session is directly available during the active time window (between start time and stop 
time). However, this Is too restrictive. It is necessary to be able to express that the 
session is available dynamically, for example via voting. Moreover, the session can be 
off-air or on-air 

3. How to get the service and where to get ft? It is necessary to be able to express the 
method of getting the service. For example, to receive an encrypted multicast service 
the user needs to send his authentication credentials to the network via a return 
channel. The user learns the IP-address of target host and the authentication 
mechanism through this extension 

Second category of extension contains the special mappings / services. There are four 
kinds of service descriptions that are needed: 

1 . Signaling the parameters of a DVB-T cell. We must be able to signal the detailed link 
level parameters of a DVB-T cell in an SDP announcement. This helps the client as the 
scanning time to find the link is greatly reduced. 

2. Mapping a set of IP multicast addresses to cell ids. Multicast sessions are earned 
on IP packets that have an multicast address. We must be able to define the mapping 
between a set of multicast addresses and the actual cell ids that contains the session. 
The receiver can then subsequently learn the cell-level parameters from the first type of 
an annoucement. 

3. What is the coverage of the service and how does it change? It is necessary to be 
able to express the coverage of the service in question in terms of logical, unique cell 
identifiers of an access system. In addtion, it is equally important to be able to signal 
the end users about future changes in the coverage. 

4. Describing logical service announcement channels. In some cases it is benificial to 
group the service announcements on a single logical channel. For example, in the case 
of DVB-T changing the reception frequency and re-tuning takes time. To help the 
receivers, there might be a cell that is used to annouce all the available sessions. One 
tuned to that cell, users receive fast all the annoucements and other mappings. 

5. Announcing unicast connectivity. This is to enable announcing of unicast 
connectivity (or to describe network access service, NAS). 
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4. PROTOCOL EXTENSION SPECIFICATION - SESSION LEVEL ATTRIBUTES 

There are two ways the following extensions in this chapter can appear. First, the new 
session level attributes can appear within a normal SDP description. In this case the 
extension attributes cannot be added, modified or removed by any third party (proxy) 
without breaking the SAP security checksum. 

Second, the new session level attributes can appear in a separate SDP description. In this 
case, there will be two (or more) announcements. The first one describes the basic 
session/service. Then, the latter one(s) just append(s) further information to the first 
description. The method to link additional annoucements to the original description is to use 
unique <sessionld> attribute. 

Using two separate annoucements is the recommended way to expand the SDP. 
4.1 Cost of service 

To be able to describe cost of a service, we introduce a new session-level attribute. 

a=cosl :<cosl> 

4.1.1 TheABNFfor<cost> 

<cod L> »" cocl-anounl space 

cost -unit space 
cos I -role space 
cosl-lype 

cosl-anounl = INTEGER 

cosl-unil - "USC* / "EUR" 

cos I -rale = INTEGER 

; in case or line based billinc 
; Ihic is I he inlerval in seconds 

cos I -type - "Line" / "sire" / "one-oTJ" 

; de.aull "one-cT^" 

4.1 .2 Example: Multicast session having time-based fee (using one annoucement) 

The following announcement describes a normal multicast session. In addition, cost- 
parameter tells that the cost of receiving the session is EUR 1 per hour. 

v-C 

0- nhandley 2GSC0<M:;26 20SCG'I20C7 IN IF4 126. 16. 64. A 
s a SDF Seninar 

i*»/\ Seninar on LUe session descriplion prolocol 
u«hL Ip: //ww. cs. ucl . qc. uX/s la "/M.Kandley/sdp. 03. ps 
e«nr h8ici. edu (Mark Kandley) 
c-IK IF<J 224.123.1.12C/127 

1- 2073357496 2073*104656 
o°recvonly 

a=cost:l Em 3600 time — 1 EUR/hour 

n=audio <IS17C R7F//\VF C 
nevideo 51372 R7F/AVF 31 
re-applicalion 32416 udp 
a«orienl:porlrail 
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4.1.3 Example: Multicast session having time-based fee (using separate annoucements) 

This example describes exactly the same information as 4.1.2, but now using two separate 
announcements. This is recommended way. 

Announcement 1 - plain service description 

v-C 

o=nhandley 2£fSC&44;;26 2G$C042£fC7 IN IF4 126. 16 . 64 . 4 
o=SCF Seninaz 

i-A Seminar cn Llie session description protocol 
u-hl Lp: //www. co . ucl . ac . uk/sLair/M. Kandley/sdp. 03. pc 
. e-rr h6ioi. edu (Mark Kandleyl 
c-IK IF<1 22<l .123.1. 12C/127 
L-20733974S6 20734C46S6 
a-recvenly 

rF-oudio <i$17C RCF/AVF C 
n«video 51372 R7F/AVF 31 
rF=applicaLion 32416 udp wb 
a»or ienl : per Lrai L 

Announcement 2 - additional cost information 

v-C 

o= opera I or 1234^6709 123456709 IK IF 4 111.122.133.144 
n*Co3t in,TemaLien 
i-/vddilicnal cccL in'emaLion 
L-20733974S6 2073404696 

a-oecoicnid: nhandley 20SC044526 IK IF4 126.16.64.4 
accost : l/EUR/3600/tima — 1 EUR/hour 



4.2 Availability of service (dynamic/static) and contact Information 

Active time for a service is the time between start time and stop time as expressed by the t- 
fteld of an service description. Withing this active time, the service can be available in three 
ways. First, the session can be available statically. This is the default case in basic SDP. 
Second, the service can be available dynamically on-air or off-air. The service being on-air 
dynamically means that the service is currently available. However, the service may go off- 
air withing the active time. Last, the service can be available dynamically, off-air. This 
means that the service exists, but is not on-alr currently. For example services that need to 
be voted or are based on popularity can first exist as dynamically off-air. When the service 
actually becomes available on-air, the service state changes to dymically available, on-air. 

To meet the requirements of expressing the service availablity, we introduce a new session 
level attribute 

a~a vail able: <avoilable> 

When a service is announced as dynamically available, but currently off-air, we often need 
to specify how to get the service and where to contact. A new session-level attribute serves 
the purpose. 

a-conLacl :<conLacL> 
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4.2.1 The ABNF for <available> 



<available> « "sialic" 

/ B dynanic/on-air n 



/ n dynonic/cJJ-air n 

xS this allribule is nol present, 

de'aull by RFC-2227 is "sialic" 

in case o.T dynamic /on-air cz dynamic/ eJr-air, 

consul I n a=conlacl" 



4.2.2 The ABNF for <contact> Is: 



<ccnlacl> - con lac I -address conlacl-lype 

conlac I -address - IF 4 -address 

"Where lo cel B 

— Address oZ allendanl / server / :'oin listener 
vliere lo send joins, elc 

conlacl-lype ° prolocol 

; "How Lo eel" 

prolocol = "IGMF-JCIK" / n IGMF-VC7E n / "K/V.F" 

4.2.3 Example: Session available dynamically, currently off-air (using one annoucement) 

The following announcement describes a normal multicast session, which is offered to the 
end users. However, the session is not yet on-air (it's state is dynamic/off-air). Users can 
vote for the session to become on-air by sending a special IGMP-VOTE message to a host 
attendant.ucl.ac.uk. 

v=C 

c-nhondley 2GSf 00^4^26 202C0<120C7 IN IF<1 126. ie, 6<i . A 
s-SCF Seminar 

i«=A Seminar on Ihe session description prolocol 

u-hl Ip : / /ww, cs . ucl . ac . uk/ a laJJ/M . Handley/sdp. C 3 . ps 

e«rrheici. edu (Mark Kandley) 

c-IN IF4 224.123.1.12C/127 

l«2G733$7dS6 2073<lC'i6S6 

a~recvonly 

a=available: dynamic/off-air 

— see the <oontact> parameter to see more 
a=contact : attendant . ucl . ac . uk/ IGMP-VOTE 

n-audio 4S17C FCF/AVF C 
n-video 31372 RCF/AVF 31 
n-applicalion 32416 udp vb 
a- orient -.portrait 

4.2.4 Example: Session available dynamically, currently off-air (using separate announcements) 

This example describes exactly the same information as 4.2.3, but now using two separate 
announcements. This is recommended way. 

Announcement 1 - plain service description 

v-C 

c-nhandley 2OSC0>M*;26 2&$C0420C7 IK IF4 126.16.64.1 
s-SCF Seminar 

i-/\ Seminar on Ihe session description prolocol 
u-htlp; //vww . cs . ucl . ac.uk/rla "r/M.Kandley/sdp. C3. ps 
e-rrh9isi.edu (Mark Handle*/,* 
c-IK IF4 224.123. 1.12C/127 
1=2073397426 2G734C46S6 
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a«recvcnly 

n^audio 4S17C R7F/AVF C 
n=video 51372 RTF/AVF 31 
r^opplicotxon 324 1€ uUp *b 
a-cr ienL ; per Lroi I 

Announcement 2 - additional availability Information 



c»cperalcr 123456709 123456709 IK IF4 111 . 122. 133 . 144 

i D Addi Lionol cod irComoLxcn 
1-20733S7496 20734C46S6 

a-aeccioniU: nhandley 2£<SC044;;26 IK IF4 126.16. 64. 4 
a=available: dynamic/off-air 

— see the <oontact> parameter to see more 
a=contact: attendant . ucl . ac . uk/IGMP-VOTE 
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5. PROTOCOL EXTENSION SPECIFICATION - SPECIAL MAPPINGS 

5.1 DVB-T cell parameter announcement 

This announcement describes the physical transport parameters of a single DVB-T 
broadcast cell. The following ABNF extends the SDP syntax defined in RFC 2327. In 
addition, new session- and media-level attributes described below are defined for the 
announcement. 

The complete DVB-T cell parameter announcement thus consists of two parts: connection 
parameter and cell-describing attributes as session-level or media-level parameters. 

c=<nel lype> <addrtype> <connection-addresc> 
<cel 1-attr ibute-Jields> 
<cell-nedia-.Tields> 



5.1.1 The ABNF for <nettype>, <addrtype> and <connection address> 



<nel Lype> 
<addrtype> 



"DVE/CELZ" 

- "IF'!" / B £I n 

IF4: IFvl address identifies the cell 
SI; cell_id in DVB Service In! or no lien 
identifies Lhe cell 

note - should be extended later to support IPv6 as well 



<connect ion- addr ess> 



dvb-cel 1 -add i 



dvb- ce 1 1 -add r 
dvb- cell-ipd- addr 

dv b- ce 1 1 - s i - addr 
orlcinal-netwrk-id 

dvb- cell-id 

decina 1 -us ho r t 



= dvb-cel l-ip4 -addr / dvb-cell-si-addr 
= uni cast -addr 

; unicast-addr defined in RFC 2327 

; note - private IF addresses should NOT be used 

; as cell ICs 

« ericinal-network-id dvb-cell-id 
= decinal-ushort 

; oricinal_netwrk_id defined in DVB SI 

» decinal-ushort 

; cell_id defined in LVB SI 

- 1* (digit; 

; unsicned 16 -bit intecer 



5.1 .2 The ABNF for <cell-attribute-fields> 

<cell-at tribute-fields - nomal-cell-at tribute-fields 

/ abbre via ted- cell -at tribute-fields 
; based on <attribute-fields> defined in RFC 2327 
; mandatory sub-fields indicated in cements below 

nomal -cell-attribute-fields ° MV nomal-cell -at tribute CR1F) 

abbreviated-cell -at tribute-fields - *("a~ n a Lbreviated-cell-at tribute CR1FJ 



noma! -cell-attribute 



bandwidth 

/ If t -node 

/ constellation 
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/ code rale 

/ cuard-inlerval 

/ hierarchy 

/ hi erarcliicol -priority 

/ dvb-.Traninc 

/ noma! -bearer 
; these CVB-C paronelerc defined in the 
; EVE £1 speci Jicalion 



a bbr ev i a I ed-cel 1 -a 1 1 r i bu le 



dvb--Tronunc 

/ abbrevialed-bearer 



bandwidth 

m-node 

constellation 

cede rale 

cuard-inlerval 

hierarchy 

hierarchical -prior i Ly 

dvb-rraninc 
dvb- Zz aninc-node 

nomal -bearer 

abbr eviaL ed- bear er 

nomal -dvb-bearer 
abbr ev i a L ed-d vb-bea r e r 



= "dvb-l-bandwidlh: 
; nandalory 



bandwidlh-ol I ribule 



bandwidlh-al tribute 



- "dvb-l-m:" JT'l-ncde-allribule 
; nandalory 

= "dvb- l-cons lei lotion: " conslello lion-all ribule 
; nandalory 

s n dvb-l-coderale:" coderale-allrilxile 
; nandalory 

= "dvb-l-cxiard-inlerval; " cuard-inlerval -a I LribuLe 
; nandalory 

o n dvb-l-hierarchy: " hierarchy-all ribule 
; nandalory 

« "dvb-l-hierarchical-priorily: n 
hierarcliical-priorily-al tribute 
; icnored ±~ hierarchy — "none" 
; nandalory ±1 hierarchy I- "none" 

- "Iraninc:" dvb- Irani nc -node 
; nandalory 

« "dvb/npe" 

; EVE nul Li protocol encapsulation, 

; other alternatives could be added here 

= "bearer:" nomal-dvb-beorer 
; nanda lory 

« "bearer:" abbr evi a led-dvb- bearer 
; nandalory 

- "dvb- I" 

« "dvb-l" 

space bandwidth-attribute 

space JJt-node-at tribute 

space constellation-attribute 

space coderate -at tribute 

space cuard-inlerval -at tribute 

space hierarchy-al tribute 

[ space hierarchical -priori ly-at tribute ! 

o "7" / "0" 

; bandwidth in MHz 



m-node-a It ribule 



= »2" / "0" 

; FFT node used* 2 k or OK 
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constellation-attribute ° "QFSK" / "l€O r W" / "€<lC;*r 

coderate-attribute - "1/2" / "2/3" / "3/4" / "i/6" / "7/0" 

cuard-intervol-attribute- "1/32" / "1/16" / "1/0" / "1/4" 

iiierarchy-at tribute - "none" / "1" / "2" / "<1" 

; alpha value Zoz 

; liierarcliical codinc, or "none" iZ 
; liierarcliical codinc is net used 

liierarcliical -priority-attribute ° "low" / "hich" 

5.1.3 ABNFfor<cetl-media-fields> 

<cell-nedia-rieldo> = 1* (cell-nedia-rield; 

cell-nedia-Jield - "n-nas/none" CKLF ce 11-nedia-attri bu tec- 

eel 1-nedia -at tributes *• l*("a«" cell-subcell -at tribute CFCF) 

cell-subcell-attribute - "subceil:" [ dvb-subcell-id space ! 

eel 1 -cent r al -Z r equency-a t tribute 
{ "/" cell-coverace-at tribute \ 

dvb-subcell-id - decinal-uchar 

; decinal-uchar de-Tined in RFC 2327 
; subcell_id defined in CVB SI 

eel 1 -central -.Trequency-at tribute - Jloat 

; central frequency in MHz 

cell-coverace-attribute « "coverage:" center-ccord "/" radius 

Jlcat - * (DIGIT! 1* (DIGIT; 

center-coord - Tloat ("K" / "S"! V" Ileal ("E" / "W") 

; in decrees, latitude and lencitude 

radius - -loat "/" -lcat 

; in kilonelres, north-south and east-west 

5.1 .4 Example: Mapping of (sub)cell ids - normal notation 

The following announcement introduces a DVB cell, identified by the IP address 
15.21 .12.34. The session-level attribute fields with the prefix "dvb-t-" descibe DVB-T link 
level parameters, common to all subcells of a DVB-T ceil. Last, two media sections in the 
end identify two subcell s with subcell IDs 1 and 2, each with different geographical 
coverage. 

v-C 

o=- 'I3C^53C02 23236^346 D\ IF 4 131.220.32.5$ 
s=KetworK /vecess Service (K, r \S! announcenent 
i-»Faraneters oZ a CVB-T cell and subcells 
o=DVB/CELL IP4 15.21.12.34 
a=dvb-t-bandvidth : 8 
a«dvl>-t-£ft:e 

a=cTvrb-t-const©llation: 16QAM 
a=dvb-t-co derate : 2/3 
a=dvb-t-guard-interval : 1/8 
a=dvb- t-hi er archy : none 
af=dvb-t-hiexarchioal-prioarity: high 
a^fr anting: dvb/npe 
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a=bearer : dvb - 1 

1-HS032CC 1274217 
ro=nas/none 

a»SUbcoll:l 450.2/60. 31N/12 . 44E/3. 1/2. 5 
nFroas/none 

a=subcell ; 2 516 . 3/60. 28N/12 . 45E/2 .9/2.8 



The following announcement descibes the DVB-cell in a shorter, abbreviated notation. This 
notation bundles all the link-level parameters of a DVB-T cell into one bearer attribute field. 

In this case, the cell is identified by the IP address 15.21 .12.35 and contains just one 
subcell (a DVB-T ceil always consists of at least one subcell in the ASAB announcement 
syntax). The optional subcell ID parameter has been omitted from the zubceii field, as 
there Is no need to differentiate between the subcells of this cell. 

v-C 

o=- <i3CS93CD2 2323603^6 IN IF<1 131. 220. 32. 
o-NeLwork Access Service (N/VSI announcenenl 
i=FaraneLerc or a EVE-T cell and subcells 
C=DVB/CELL IP4 15.21.12.35 
a— framing: dvb/nipe 

a=bearer:dvb-t 8 8 16QAM 2/3 1/8 none 

L-4S032CC 1274217 
n=nao/none 

a=subcell : 4 91 . 23/23 . 5 93/ 90 . 63W/4 0 . 9/38 . 5 



This announcement describes the paramters of a DVB-T cell consisting of three subcells. 
Because the hierarchy-attribute subfield contains a value other than "none", the 
hterarchical-priority-attribute subfield must be included, and has a value of "high" in this 
case. The inclusion of subcell coverage parameters is recommended, although not 
mandatory - in this example the coverage parameters have been omitted. 

v=C 

0— 43C--S3C02 23236i3'16 IK IF<J 131.220. 32. ~S 
c -Network /vccecs Service (KAS) announcenenL 
i=Faranelers o- a DVB -7 cell and oubcellc 
o=DVB/C£LL IP4 15.21.12.36 

a=f raming : dvb/npe 

a=bearer:dvi>-t 8 8 64 QAM 1/2 1/16 2 high 

1- 49032CC 1274217 
rr^nas/none 
a=5Ubcell:l 460.1 
n-nac/none 
a=subcell:2 510.5 
n^nac/none 
a»subcell:3 570.9 



This announcement identifies one or more DVB broadcast cells, and for each cell describes 
the group of sessions being transmitted in that cell. New media-level attributes described 
below are defined for the DVB-T cell to session mapping announcements. In addition to the 
mapping announcements defined here, clients also need to receive normal SAP 
announcements describing the sessions. 



5.1.5 Example: Mapping of (sub)cell ids -abbreviated notation 



5.1.6 Example: Mapping of (sub)cell Ids -abbreviated notation 



5.2 Mapping from DVB-T cells to sessions 
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Slmilarty to DVB-T cell parameter announcements described earlier, cell-to-session 
announcements consist of two parts: a <dvt-network-connection-::ieid> identifying the 
DVB network, and media-level attributes defined as <ceii-nappinc-nedia-::ieids>. 

The following subsections extend the SDP syntax defined in RFC 2327. The ABNF entries 
ccnnecUon-rieiu and nedio-descripUonc defined in RFC 2327 are replaced by <dvt- 

neLworK-connecLicn--i©ld> and <cell-nappinij-nedio-rield2>, respectively. 

5.2.1 The ABNF for <network-connection-fieId> 

<dvb-network-connection-.Tield> - w c»" network- net type 

space network -addrtype 
space net work -connect ion -address CR1F 

network-net type = "CVB/KE:>JCRK" 

netwer k-addr type - °£I n 

network-connect ion-address - dvb-network-addr 



dvb-network-addr - ordinal -network-id 

oricinal-net work-id 63 decinal -usher t 

; oricinal_network_id defined in DVB £1 

deciral-ushort » 1*(DIGI7; 

; unsigned 16 -bit integer 

5.2.2 The ABNF for media-ievel attributes 

<cell-nappinc-nedia-~ields> - 1* ("n-nas/ncne" CR1F 

cell-connection-Jield CR1F 
cell-nappinc-at t ribuLe-Tields) 

cell -connect ion--Ti eld - "c-" net type space eel 1-c-addr type -add r 

cell-nappinc-attribute-rields ° l*( n a«" unique-session-id-attribute CRLF) 

cell -net type = "DVB" 

cell-c-addrtype-addr - "CELL" dvb-cell-addrtype dvb-cell-addr 

unique-cesoion-id-ot tribute * "secsionid:" usernaoe space sess-id space 

net type space addrtype space addr (";" Limine! 
; clobally unique session identifier that naps to 
; the "o**" field ol on RFC 2327 session announcenent 

dvb-cell-addr type - n IFd n / "SI" 

dvb-cell-addr = dvb-cell-ip>1-addr / dvb-cell-si-addr 

usernane - safe 

; use mane and safe defined in RFC 2327 

sess-id - 1* (DIGIT: 

; sees -id defined in RFC 2327 

; should be unique Tor this oricinatinc usemarae/host 

addrtype - "IF*1 W / "IF6" 

; addrtype defined in RFC 2327 



IMOKJA 



ASAB PROTOCOLS 



16 (2W) 



Nokia Research Center 
Toni Paila 



vO.055,1 



addr 

civb-cell-ipK! -addr 

dvb- ce 1 1 -s i - addr 
or icinal-nat work-id 

dvb- cell -id 

decimal -us hort 



= FQCK / unicast -address 

; addr, FQDN and uni cast-address defined in RFC 2327 

- unicast-oddr 

; unicast-oddr defined in RFC 2327 

- oricinal-net*ork-id dvb-cell-id 
«■ decinol-ushort 

; oricinal_netxork_id defined in DVB SI 

» decinal-ushort 

; cell_id defined in CVB £1 

- 1* (DIGIT) 

; uns icned 16-bit intecer 



5.2.3 ABNF for <timing> 



<Lininc> 



• start-tine stop-tine 

Lhe Line this a L tribute becomes active 

- I J tininc does not exist, assure session 
level I -attribute 

- IT start-Line «= C, assune session level star t-tine 

- 11 stop-tine — C, assune session level stop-tine 



5.2.4 Example: DVB-T cell to session mappings 

The following announcement declares that the DVB cell identified by IP address 

15.21 .12.34 contains three multicast sessions and the cell identified by IP addrss 

15.21 .12.35 contains four multicast sessions. The contained sessions are refereed with 
session Id-attribute. Note that both cells contain the session (a=sessionid> 3398739487 IN 
IP4 136.34.12.2). Note also that the session (a=sessionid> 3398739487 IN IP4 
136.34.123.26) Migrates from cell 15.21.12.34 to 1521.12.35. The transition takes palce 
during time interval 344430000.. .344450000. 

v~C 

o— 3374-;732S'l 33SfS1072d2 IK IF4 dotacact . dici La. Ji 
s -Network /Nccess Service (K/VS) announcenent 
i«Mappinc Izcn C\"B-T cell (c) to sessions 
c=DVB/NETWORK SI 32765 
t=33S071^07d C 
xmas/none 

c^DVB/CELL ZP4 15.21.12.34 

assess ionid: - 3398737481 IN IP4 136.34.12.2 
a=sessionid: - 3398739487 IN IP4 1 36.34.123.2 6 0 344450000 
a=sess ionid : - 3398983458 IN IF4 msdiaoast.sonera.fi 
a^sessionid: admin 3398778932 IN IP4 138.34.253.9 
msnas/none 

o=DVB/CELL IP4 15.21.12.35 

assess ionid: - 3398737481 IN IP4 136.34.12.2 
a=SGSSionid: - 3398739487 IN IP4 1 36.34.123.2 6 344 4 30000 0 
assess ionid: - 3398983453 IN IP4 mediacast.sonera.fi 
a=sessionid; root 3398798446 IN IP4 139.43.56.76 
a=sess ionid: demo 3398773348 IN IP4 madiacast.sonera.fi 
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5.3 Mapping from sessions to DVB-T cells 

It Is necessary to be able to define the coverage of a service in terms of logical scope. We 
define the scope in terms of a list of cells. In addition, it is necessary to describe such 
actions as coverage expansion, coverage contraction and migration of service from a cell to 
another. This section explains how to achieve all this. 

We intruduce a new announcement that identifies one or more sessions, and for each 
session describes the group of DVB-T cells where the session is being transmitted. New 
media-level attributes described below are defined for session to DVB-T cell mapping 
announcements. In addition to the mapping announcements defined here, clients also need 
to receive normal SAP announcements describing the sessions. 

Similarly to DVB-T cell parameter announcements described earlier, cell-to-session 
announcements consist of two parts: an optional <dvt^network-connection-rieid> (defined 
in 5.2.1) identifying the DVB network, and media-level attributes defined here as <-e— - 

nappinc-rtedi a- IX eldc> . 

Ttie following ABNF extends the SDP syntax defined in RFC 2327. The ABNF entries 
conneciion-rieiu and nedi a -descriptions defined in RFC 2327 arc extended by <dvb- 

neLvorK-connecUicn-rield> and <cec^-nappin«r-nedio-Ji.elUc>, respectively. 



5.3.1 The ABNF for media-level attributes 

<5ecc-noppinc-netUa-Jiel<j£?> ° 1* ( n o=nac/non© n CK1F 

n a=" unique-oession-id-at tribute CK1F 

z- ec a -noppi i*r - a t L ri bu L e - Zi e ldo ) 

; unique-sec c ion -id-at tribute defined earlier 

secc-nappinc-attribute-Jieldo - l*( B a«" ceil -id-attribute CR1F) 

cell-id-attribute - "cellid:" dvb- C ell-addrtype space dvb-cell-addr 

["/" cell-id-rance; [":" tininc; 
; dvb-cell-addr type and dvb-cell-addr defined earlier 

cell-id-ranre = PCS -DIGIT * (DIGIT J 

; nunber oZ consecutive cell ids - i_" no 
; cell -id-:: once ic civ en, is assumed 



5.3.2 Example: session to DVB-T cell mappings 

The following announcement is an example of DVB-T cell mappings. All media descriptions 
in cell mappings start with the "m=nas/none" m-field 2 . In each media description, a session 
identided by the sessionid field is mapped to one or more DVB-T cells identified by ceiiid 
fields. Because multiple media descriptions can be included in an announcement (as with 
standard SDP [1]), this announcement format allows any number of sessions to be mapped 
to the cells delivering those sessions. 

The inclusion of a ofield with the networkJdenBfier [8], [9] of a DVB network is 
recommended but not mandatory. 



2 The syntax of this form of the m-fieJd originatesfrom the Media Gateway Control Protocol specification [6] 
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v-C 

o»- 337di722Si 33S$1G72<13 IN IF4 datacact.dicita.fi 
G°KelwrK s\ccesa Service ( KAS J announcenent 
i-Woppinc; fren cession (:? ) Lc DVB -7 eel la 
C^DVB/KBTWCRK SI 32765 
U-33S071^07d C 
nmas/none 

a^sessionid: - 3398739487 IN IP4 136.34.123.26 
a=cellid;IP4 15.21.12.34 
a=cellid:IB4 15.21.12.35 
ro=nas/none 

a=sessionid: - 3398983458 IN IP4 madiacast.sonera.fi 
a=collid:IP4 15.21.12.34 
a=collid:IP4 15.21.12.35 
nF=nas/none 

a=sessionid: admin 3398778932 IN IP4 1 38.34.253 .9 

a»oellid:IP4 15.21.12.34 

m=nas/none 

a^sessionid: root 3398798446 IN IP4 139.43.56.76 

a=collid:IP4 15.21.12.35 

npnas/none 

assess ionid: demo 3398773348 IN IP4 mediacast.sonera.fi 
a=cellid:IP4 15.21.12.35 

5.4 Describing logical service announcement channels 

In this case we want to announce the presence of a logical channel (for example a cell) that 
further contains service announcements. We achieve this with a new individual SDP 
description. The method Is modified from a proposed way of describing session derectories 
with SDP [3]. 

TTie session-level connection parameter (c-field) specifies the actual multicast address of 
the announcement channel. Then, session-level attribute a-cellid uniquely defines the cell, 
In which the above mentioned multicast address is available. Media parameters are set os 
descrbed in [3]. Last, media-level attribute a=cellid can be used to specify to which cells the 
announcements belong. 

5.4.1 ABNF for a logical service announcement channel description 

< logical service announcenenL channel description 

■ v -fie Id 
o-field 
j-field 
c-field 

* (cell-reference; 
* (sdr -media -bundle ) 

cell -reference a cell -id-a I tribute 

rdr-nedi a -bundle - odr-nedia-f omoL 

* (cell -reference) 



5.4.2 Example: announcing neighbour control channel of neigbouring cells 

The following description presents an example how a cell can announce the control 
channels of it neigbour cells. These channels then in turn contain majority of 
announcements related to the espective cell. 
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o-nhandley 2(i<iC(i44Z2G 2090042007 IK IF4 126. 16 . €4 . 4 
s^Locical control channel announcenent 

c°IK IP'i 224 .2. 127. 2S2/2ii — UEA specific cell-locol-ann. multicast croup 
a=cellid:IP4 15.21.12.22 — Where is the xaoast address of c- field available 
t-C C 

ro=*appl ioation 9875 SAP SDP 

a=cellld:IP4 15.21.12.22 — Target cell #1 to be described 
a=cellid:IM 15.21.12.23 — Target cell #2 to be described 
a=cellid:XP4 15.21.12.24 — Target cell #3 to be described 



The following presents an example of how to announce logical announcement channels 
with SDP. The service description below expresses that the IP address 224.2.1 27.252 
carries a control channel for cells 15.21.12.34, 15.21.12.31 and 15.21.12.32. For the first of 
these the description protocol is SDP and for the two last ones the description protocol is 
SDL-XML The identical service announcement channel canrying 224.2.127.252 is available 
in cells 15.21 .12.22 and 15.21 .1226. 

v-C 

o-nhandley 20SC0'Hi;26 20$C0<120C7 IK IF4 126. 16 . 64 . <J 
c -loci col control channel announcenenl 

c*»IN IF4 224.2.127.2^2/255 — UBA opeciJic cell -local -arm. multicast croup 
a=cellid:IP4 15.21.12.22 — Where is the mcast address of c-field available 
a=cellid:IP4 15.21.12.26 — Additional cell, where the roc addr is available 

L-C C 

misapplication 9875 SAP SDP 

a»ceUid:IP4 15.21.12.34 — Target cell #1 to be described 
ra==appl i cat ion 9876 SAP SDP-XML 

a=cellid;IP4 15.21.12.31 — Target cell #2 to be described 
a=cellid:IP4 15.21.12.32 ~ Target cell #3 to be described 



This announcement defines the mapping of DVB service components to IP addresses 
within a single DVB-T broadcast cell. These announcements only need to be transmitted in 
cells carrying IP data on more than one PID. 

The DVB service component to IP address mapping consists of two parts: a <dvb-ceii- 
conneciion-rieiu> identifying a DVB cell, and media-level attributes defined as <conp- 

nappinc-nedia-Jieldc>. 

The following subsections extend the SDP syntax defined In RFC 2327. The ABNF entries 

connecllon-rield and nedia-<Jeccriplionr defined In RFC 2327 are replaced by <dvb- 
cell-connection-"ield> and <conp-nappln>;-nedia-rieldc> l respectively. 

Notice the slightly non-standard use of the subnet mask length in the subnet-oi tribute 
field defined below. In ASAB announcement protocol, the subnet mask length is used to 
indicate individual IP addresses or address ranges, for both unicast and multicast IP 
addresses. If the subnet mask length is smaller than the length (in bits) of its associated IP 
address, a range of IP addresses is described. However, if the subnet mask has the same 
length as the IP address, an Individual IP address is indicated. 



5.4.3 Example: describing control channel 



5.5 Mapping DVB service components to IP addresses 
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For example: 

subnet ; 224 .C.C.C/16 — A subs eel ion oJ the multicast IF address 

— ranee (224.C.C.C - 224.0.2^.2^) 

subneL:236.2*;.243.1SC/32 -- An individual multicast IF address (236.25.243. 190) 

5.5.1 The ABNF for <cell-connectton-field> 

<dvb-cell -connect ion-JTield> = "c«" cell-net type 

space eel 1-addr type 

space cell -connect ion- address CK1F 



cell-net type 
cell-addrtype 



"DVB" 



cell -connect ion-address ° dvb- cell-addrtype space dvb-cell-addr 

; dvb-cell-addr type and dvb-cell-addr de lined earlier 



5.5.2 The ABNF for <comp-mapping-medIa-fields> 

<conp-nappin«r-nedia-Jields> - 1* ("n=nas/none" CR1F 

conp-connection-.Tield CRLF 
conp-nappi no - a 1 1 ri bu t e - .Ti elds I 

conp-conneel icn-Jield = n o=" conp-c-net type- addr type space 

ser vi ce-cenponen t 

conp-c-net type-addrtype « "CVE/SERVICE" 

conp-nappi ne -at tribute-Jields = l*( n a=" subnet -at tribute CR1F) 

subnet -at tribute « "subnet:" subnet-net type space subnet-addrlype space 

subnet-addr "/" subne t-nask-lencth 
; describes an address ranee 
; extends the deJTinition Jron RFC 27 
; note - subnets beine transmitted vritliin the sane 
; CVH-T cell nust not overlap 



subnet -ne t type 
subnet -addr type 
subnet-addr 

subne L -nas k- 1 enc 1 1 i 

service-conponent 

subnet 

ser*/ ice- locator 



"IK" 

"IF4" / "IF6" 

unicast -address / nulti cast -addr ess 

uni cast -addr ess and nulti cast -addr ess defined 

in RFC 2327 

decinal-uchar 

lenoLh (in bits) o* the subnet nasK 
decinal-uchar defined in RFC 2327 

service-locator ["/" conponent-tac; 
component -tac can be leJt out iZ the service 
contains only one data broadcast component carrying 
IF over MFE 

"IK" space 

subne I -addr t ype space 

subnet-addr "/" subne t-nask-lencth 

service-path / textual-service-identiJier 
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ccnponenl- Lac 



■ decinal-uchar 



service-pa Lh 



- oricinal-neLwrk-id "/" 

service- id 
; original -neLwrk-id defined earlier 



LexLuol-service-idenli-Tier - FQDK 

; FQCN (rully-qualiried donoin none) defined in RFC 2327 



The example below shows the mapping of the entire multicast IPv4 address range 
(224.0.0.0 - 239.255.255.255) to four components of a DVB service being broadcast in a 
DVB-T cell. The cell is identified by a c-field in the session-level part of the announcement. 
The mapping from IP address ranges to DVB service components is defined In the media- 
level part of the announcement, consisting of one or more media descriptions. Each media 
description includes a c-field Identifying a DVB service and a component within that service. 
The media description further contains one or more subnet fields that describe the address 
ranges being transmitted on the given service component. 

In this example, the selection between the four components takes place according to the 
two most significant bits of a multicast IPv4 address, following the four-bit address prefix 
that Is constant for all multicast IPv4 addresses. Thus, a subnet mask length of 6 bits is 
used in the subnet fields below. 

v-C 

0— 4 C; 022072 i £0273203'! DC IF 'J doLQcaoL.^cnero.ri 
s=Ne Lwrk toecc Service ( KA£ ) onnouncenenL 

1- IF address Lo EVE service ccnpcnenL nappincs 
o=DVB/CELL IP4 131.228.7.11 

xn=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera . fi/1 

a=submJt:IN IP4 224.0.0.0/6 

ra=nas/none 

c=DVB/ SERVICE multicast . medianet . sonera. fi/2 

a=subnet: IN IP4 228.0.0.0/6 

m=nas/none 

c=DVB/ SERVICE multicast . medianet. sonera. fi/3 

a=subnet:IN IP4 232.0.0.0/6 

m=nas/none 

o=DVB/ SERVICE multicast. medianet. sonera. fi/4 
a»subnet:IN IP4 236.0.0.0/6 



Access mappings enable clients to obtain a return data path to a media operator that offers 
a datacasilng service via DVB-T. Clients can then be provided with a "hybrid network" 
connection to the Internet, where the forward data path is provided via DVB-T and the 
return data path via some other network. The availability of a return data path enables 
clients to use unicas! protocols and/or participate in 'Voting" for the selection of dynamic 
multicast content on the DVB-T network. 



service-id 



= decinal-ushorL 

; decinol-ushorL defined eorlier 
; service id defined in DVB SI 



5.5.3 Example: Mapping IP addresses to DVB service components 



5.6 Access mappings 
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By sending access mappings, datacast operators can provide clients the IP address of a 
login server or the phone number of a modem pool. Providing an IP address is preferable, 
as clients are then free to use any Internet Service Provider (ISP) for connecting to the 
media operator. General-purpose ISP phone numbers may also be advertised using 
access mappings, without requiring the client to use a particular ISP. 

Access mappings consist of standard SDP session and time attributes, followed by the 
media-level attributes defined in the following as <access-media-fields>. 

5.6.1 The ABNF for access mappings 

<access-nedia-.Tields> - 1* (access-nedia-fieldj 

access -nedia -field = n n=" access-nos-f ield CFCF access- connect ion- field CR1F 

access-attribute-fields CR1F 

access-nas -field - n nas/ n nas-authentication 

access -connect ion-field - n c- n c-access-nettype space c-access-addrtype space 

c-access-ccnnect ion- address CR1F 

access-allribuLe-Iields = l*("a=" access-attribute-field CR1FJ 

; nandaLory access attributes indicated below 

nas-authentication « "none" / "locin" / "chap" / "pap" / "ipcec" / "12 Lp" 

; Lhese authenLicaLion nethods defined in RFC 27 C 3 

c-access-net type = "IN" / "TK" 

; 7K Jos Telephone Network, as in RFC 2040 

c-access -adds type - in-addrtype / tn-addrtype 

c-access-connection-addr ess = in-connec Li on- address / Ln-connec Lion-address 



access-attribute-field - franinc -at tribute 

/ bearer-aLLribuLe 



/ eel 1-id-aL tribute 
/ subnet-aLLribute 

nandaLory cell -id-attribute defined earlier 
subnet-attribute defined earlier 



in-addrtype - "IF4" / "IF6" 

tn-addrtype - "RFC2;H3" 

; this address type defined in RFC 2040 

in-connect ion-address = FQCK / unicost-addr 

; FQCK and unicast-addr defined in RFC 2327 



tn-connect ion-address 
franinc-at tribute 



= inp-addr / ldp-addr 

- " franinc : " franinc -node 

; indicates the layer 2 franinc used 

; extends the definition fron RFC 27 Ci 



bearer-attribute - "bearer:" bearer-Lype 

; ex Lends the definition fron RFC 27 CO 

inp-addr - " " FCS-CIGI7 C*( ("-" DIGIT) / DIGIT I 

; clobal phone nunber, 
; defined as INF/vldr in RFC 2040 
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ldp-addr 



ranlnc-node 



bearer-type 

noderv-bear er 
icdn-bearer 

noden- o t anda rd 

noden-nanuroc Lurei 
iodn -standard 



digic c*(C- n ciGir: / digit; 

local phone number, 

defined ac- "EFAddr in RFC 2 (MO 

dvb-rraninc-nede / 
n ppp-rync n / 
"ppp-asynch" / 
"ppp-lidlc" / 
"clip" / 
"a synch" 

dvb-rroninc-node defined earlier 

- ncmal-dvb-bearer / noden-bearer / isdn- bearer 
nomal-dvb-bearer deJined earlier 

- noden-standard ["/" noderv-nanu'acturer [ 

'■ n ic*dn" *(CIGI7; ["/" icdn-otandard; 
exanple values: "isdni;*;", n icdn6'l n , 
n icdntH/v.llC n , n icdn(H/v. 120" 

' ("v." l*(alpha-nuneric) I / 

"x2 B / 
w k£6Jlex n 

exanple values: n v.32", "v. 3d", n v.2C n , n x2 n , "Kitriex" 

exarqple values: "3coiV, "rocXvell" 

• l*(sare) 
exanple values: "v.llC", n v.l2C n 



5.6.2 Example: Announcing a return data path to a media network operator via a modem pool 

The following example announces two dial-in modem numbers that clients can use to 
obtain a return data path to a media operator. The cell id(s) associated with each phone 
number indicate the recommended dial-in number for clients, based on the location of each 
client. 



Each phone number is announced within a media description that starts with an m -fie Id. 
The m-field is of the format "nr^nas/xx* 1 identifying an authentication method for a Network 
Access Service, as defined in [6]. In this example, the authentication method "login" 
Indicates that end-users will be prompted for a username and password for authentication. 

Each media description contains a c-field describing a connection address for the return 
data path, given in this example as the phone number of a modem pool. Additional 
parameters describing the modem type (bearer attribute [6J) and link-layer framing (jraninc 
attribute [6]). Finally, one or more cells are Identified (using the ceiiid attribute) as a target 
area where each return data path connection address should be used - for example to 
provide a local PSTN number to end-users where possible. Note that the same cell id can 
be listed in more than one media description within an access mapping. 

v-C 

c — 34 6232972 920CC2;M3 DC IF 4 131.220. 32. 
s-Kelwcrk /vccecs Service (N/\£) anneuncenent 
i-Subnel Tor CVB MFE encapsulated IF data 
nF=nae/ login 

o^TN RFC2543 +358-2-2340982 
a=*framing: ppp-asynch 
a^bearer : v . 90 



NOKIA 



ASAB PROTOCOLS 



24(254) 



Nokia Research Center 
Toni Paila 



a=collid:IP4 160.237.53.1/8 
xn=nas/ login 

RFC2543 +358-3-5837272 
asframing: ppp-asynch 
a=bearer;v.90 

a=cGllid;IP4 160.238.45.1/4 
a=COlUd:IP4 160.238.46.1/4 

5.6.3 Example: Announcing a return data path to a media network operator via Internet 

Similar to the the previous example, the following announcement describes the connection 
addresses for obtaining a return data path to a media operator. As in the above example, a 
number of cells is mapped to each connection address. The difference to the proceeding 
example is that each connection address here is given as an IP address. This allows clients 
to use their most preferred Internet Service Provider to connect to the indicated IP address. 

v«C 

e— 34 62 32 5*7 2 S20CC25d3 IN IF 4 131.220. 32.59 
c-KeLvork Access Service (NASJ announcement 
i-£uLnet Jcr CVE MFE encapsulated IF data 
ro=nas/ login 

o=IK IP4 portall.iDediacast.sonora.fi 
a=cellid:IP4 160.237.53.1/8 
m=nas/ login 

o=»IN IP4 portal2.xnedlacast.sonera.fi 
a=cellid:IP4 160.238.45.1/4 
a=cellid:IP4 160.238.46.1/4 

5.6.4 Example: Announcing connectivity to an Internet service provider via a modem pool 

While the earlier announcement leaves clients with the freedom of choosing an ISP, a client 
may not always be configured with the current ISP connectivity details. This announcement 
informs clients about available ISP dial-in numbers. One or more Cell ids are optionally 
associated with each phone number, to indicate the recommended ISPs for clients 
depending on their location. 

v«C 

c~- 346232572 S20CC2043 IN IF4 131.220. 32. £S 

0- Ketwork Access Service (KAS) announcement 

1- Internet Service Provider connectivity in ~o 
m==nas/ login 

C=TN RGF2324 +358-9-6524827 
asframing; ppp-asynoh 
a=bearer;v.90 

a=cellid:IP4 160.237.53.1/8 
arenas/ login 

0=TO RCF2324 +358-3-3157161 
a=f r aming : ppp-asynch 
a=bearer:v.90 

a=cellxd:IW 160.238.45.1/4 
m=nas/ login 

c^TN RCF2324 +358-2-4182732 
asframing: ppp-asynch 
a=bearer:v.90 

a=cellid:IP4 160.238.46.1/4 
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1. INTRODUCTION 

This is the collection of specifications for the announcement server to be build in the project 
ASAB (Advanced Service Announcement for Broadcasting). 

This specification is divided into three parts. In the first part we the functional (or 
architecture) specification of the server. This includes background and context for the 
system. In addition, we describe the system giving an overview and explaining the 
functionalities to be implemented in the announcer. 

The second part is the server technical (or component/implementation) specification of 
tryhe server. 

The last part serves as test specification. 

The common terms of reference used in the project ASAB are listed in the Annex A. 
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2. REFERENCES 

[1] Session Description Protocol, RFC-2327 
[2] ASAB Requirements specification, ASAB-D1 
[3] ASAB Protocol specification, ASAB-D2 
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PART 1 - SERVER FUNCTIONAL SPECIFICATION 
3. CONTEXT 
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Figure 3-1, The reference network topology 

The Figure 3-1 illustrates the reference network topology we consider In project ASAB. 
Additionally, the figure shows the logical placement of service annoucement server with 
respect to other entities In the network. 
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4. FUNCTIONAL ARCHITECTURE 

WM 




Figure 4-1, Functional architecture of the service announcing system 



The functional architecture of the entire service a nnou cement system with is depicted in the 
Figure 4-1 . The main functional components are: 

Announcement server 



The announcement server is the main component of the system. It takes care 
about composing the service announcement, sending them out as SDP over 
SAP and rescheduling them. The announcement server is associated with a 
set of databases, which define its configuration and behaviour. 



Cell broker 



There is one cell broker per one logical cell in the system. The cell broker is 
actually a system function, which can is implemented by the last hop 
announcement server associated with a particular cell. Depending on the 
config (juration, the announcement server can act as a plain annoucement 
server, a cell broker, or both. 
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TTie cell broker is in charge of what is announced in the ceD it has control 
over. TTie cell broker receives SDP announcements from two sources. First, it 
receives announcements from the other announcement servers in the 
backbone as ASAB internal multicast transmissions. Second, the 
annoucement server is associated with a set of databases that desribe which 
service annoucements to compose and send. 

Thus, the cell broker function Is to decide which announcements should be 
transmitted to the actual cell. Also, the cell broker does translation between 
ASAB internal SAP multicast addresses to the multicast addressing used in 
UBA. Last, the cell broker ensures that the pace of announcement sending 
complies with the agreed bandwidth limits. This means that the cell broker 
acts as logical a filter-mapper-scheduler. 

Database servers 

The database servers contain four logical databases. First, the service 
description database contains the incredients for the base SDP [1] service 
announcements. The second database, the announcement control 
Information database contains the control information about how to announce 
services described in the first database. Third, the mapping databse contains 
the special cell-to-IP and connectivity mappings defined in ASAB protocol 
specification [3], Last, the configuration database contains information of how 
the server is configured to wortc. 

it Is envisioned that every announcement server (whether implementing cell 
broker functionality or not) has a local database server associated. However, 
this is not required. An annoucement server could use a local database for 
configuration and connectivity mappings, for example. The same server could 
then use a centralised, remote database for fetching the service descriptions. 



Management interfaces 

Each of the main components has a management Interface. The purpose of 
these interfaces is to allow system manager to monitor and adminstrate the 
server. Also, these interfaces provide other UBA system modules a way to 
inter-operate with the announcement server system. 
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PART 2 - SERVER TECHNICAL SPECIFICATION 
5. ANNOUNCEMENT SERVER 
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Figure 5-1, Announcement server components 

Components of the announcement server include 

• Abstract database accessors 

• For control info 

• For basic sdp descriptions 

• For ASAB specific mapping information (extended SDP) 

• For server configuration info 

• JDBC database driver 

• JDBC Type-IV. 100% Java 

• DB Change poller 

• Polls the changes that happen In control DB 
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• When a change occurs, the target queue is modified accordingly* The 
modification might be adding/removing an SDP or adding/removing a 
control element 



• There are multiple queues in an annoucement server. The meaning of a 
queue is to enable higher level of grouping the announcements that are 
prepared at the server. The idea is that a queue represents somehow 
grouped announcements. In addition, SAP announcement that originate 
the same queue will have the same IP multicast address as 
destination.This way, annoucement servers that Implement cell brokers 
can subscribe to get certain types of announcements by just joining the 
respective multicast groups. 

• The scheduling policy of the queue depend on a single parameter, 
bandwidth limit (bwjimit). If the limit is set to 0, the queue follows blindly 
the configuration given an the controljnto DB. Otherwise the sender 
associated with the queue will requlate the pace of transmissions. 



• Multicast receiver and multicast-group-to-queue-mapper 

• This does essentially the same as DB change poller. This component 
installs new descriptions into correct queues as soon they are received. 



• Queues 



• Multicast receiver/filter, which contains 



Interfaces to other UBA system components and management 



Management interface 



5.1 JDBC Drivers 



[Jani] 



5.2 Database accessor? 



[Jani] 



5.3 Queue 
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Figure 5-2, Queue internal buffers 



5.4 MultJcastReceiverMapper 
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Figure 5-3, MulticastReceiverMapper operation 

The MulticastReceiverMapper structure is depicted in the Figure 5-3. There are three main 
components in a MulticastReceiverMapper. 

• MulticastUstener listens for multicast SAP annoucements via a socket. The multicast 
groups are defined in server configuration database asab_config. The groups that the 
MulticastUstener listens is sum of all the to-be-listened addresses in the database. 

• QueueMapper maps the incoming multicast SAP packets to correct queues. It uses the 
ReceiverMapperTable to achieve that. 



• ReceiverMapperTable contains mappings from a multicast address to a set of queues. 
In fact, the ReceiverMapperTable is the memory of the MulticastReceiverMapper. 



Multicast address 
(ASAB internal SAP 
address) 


Address range 


Vector of references to target queues 


224. 10.10 J2 


1 


{Queuel , Queue2, Queue4} 


224.10.15.6 


1 


{Queuel , Queue3} 


224.100.4.0 


20 


{Queue2, Queue4} 



Table 5-1, Example of ReceiverMapperTable contents 
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The basic operation of MulticastReceiverMapper is annotated with numbered steps in the 
Figure 5-3. 

0. Configuration information is inserted to ReceiverMapperTable (an example is shown in 
Table 5-1). The information originates from the database asab_config. 

1 . MulticastListener is initialised/updated with a set of to-be-listened multicast addresses. 

2. MulticastListener sends a received multicast SAP announcement to QueueMapper for 
further mapping to queues. 

3. QueueMapper queries the ReceiverMapperTable to find out which queues to send a 
copy of announcement. 

4. ReceiverMapperTable returns a vector of references to target queues. 

5. QueueMapperTable inserts a copy of the received packet to each queue referenced by 
the result vector in 4. 

5.5 DbChangePoller 



5.6 Cell broker function 

The cell broker functionality is distributed in the announcement server to several places. 
Queue configuration database holds ASAB-SAP to UBA-SAP mapping information 

• What is the target multicast group of this queue 

• Which multicast groups from the backbone will map to this queue 
It also holds the filtering information 

• If a ASAB internal multicast group does not appear in the queue 
configuration, the queue won't receive or relay any packets from that 
group 

Sender-scheduler 

• Normal announcement server queues handle this task. 



5 J File: Startup.properties 
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6. DATABASE SERVER 




Figure 6-1, E/R-model of the information in the databases 
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The database server is simple. It only consists of a MySQL server and the databases. The 
E/R-model of the information in the databases is shown In the Figure 6-1 . 



This information is consequently divided into tables. Furthermore, there are four separate 
databases which hold the tables. The descriptrions per database are: 



Database 
name 


Description 


Tables included 


asab_control 


Contains tables that define how the 
the announcements are grouped and 
scheduled. 


controljnfo 

grouped_sdp 

multicastjisten 


asab_sdp 


Contains tables that define the 
content of service/session 
descriptions 


sdp 

time_description 
attri bute_descri ptto n 
media_description 


asabjnapping 


Contains tables that define special, 
ASAB-specific mappings, such as 
cell-to-IP -mapping and NAS 
announcements 


dvb_param 

celMojp 

access_map 

nas_group 

nas_map 


asab_config 


Contains tables for server 
configuration 


queue_config 



The management interface to the databases is provided directly with the MySQL client. 



6.1 Database tables for basic session descriptions 



6.1 .1 Service description directory (TABLE asab_sdp.sdp) 



Field name 


Key 


Type 


Notes 


sdpjd 


X 


integer 


unique key, not null 


v version 




char 


v, (protocol version) 


o user name 


X* 


varchar 


o, "-" Kuser login) 


o session id 


x 1 


bigint 


o. NTP 


o version 




btgirrt 


o, increase o session! d per moorfication 


o_network_type 


x' 


varchar 


o, *W 


o_address_type 


x' 


varchar 


o, '1N4" 


o_3d dress 


X' 


varchar 


o, (address of the machine from which the session was 
created) | (FQDN) 


s session name 




varchar 


s, "MP3 stream" 


i Information 




varchar 


i*, "Nice music. 


u uri 




varchar 


u" 


e email 




varchar 


e*. 'too@bar.com" 


p phone 




varchar 


p*. See RFC-2327 


c_netwonXjtype 




varchar 


c* ( "IN" 

(connection information - not required if included in alt 



2 As defined in RFC-2327 (Session Description Protocol) 
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media) 


c_address_type 




varchar 


c*. "IP4" 

(connection information - not required if included in all 
media) 


c_connection_address 




varchar 


c', "224.2.17.12/127" 

(connection information - not required if included in all 
media) 


b bandwidth 




varchar 


b*. See RFC-2327 


z_ adjustment 




varchar 


z\ "2882844526 -1h 2898848070 <T 

note: ASAB groups all z subftelds into one field 


k method 




varchar 


kV'dear 


k_encryption_key 




varchar 


k* ( See RFC-2327 



6.1.2 Time description lookup table (TABLE asab_sdp.time_description) 



Field name 


Key 


Type 


Notes 


sdp id 


X 


integer 


to which service description this belongs, not null 


t start time 




bigint 


t 2873397496 


t stop_ time 




bigint 


t 2873404696 


r repeatjnterval 




bigint 


r*. 604800 


r active duration 




bigint 


r*. 3600 


r offsets 




varchar 


r* "0 90000" (zero or more repeat times) 



6.1.3 Session attribute description lookup table (TABLE asab_sdp.session_attribute_description) 



Field name 


Key 


Type 


Notes 


sdp_id 


X 


integer 


to which service description this attribute belongs 


media_id 


X 


integer 


to wrtch media description in session 'sdpjd' this attribute 
belongs 

(0 means session-level attribute) 


a name 




varchar 


a*, "connect" 


a value 




varchar 


a*, "1.23.4" 



6.1 .4 Media description lookup table (TABLE asab_sdp.media_description) 



Field name 


Key 


Type 


Notes 


sdpjd 


X 


integer 


to which service description this belongs 


media id 


X 


integer 


part of key 


m media 




varchar 


m, "videtf ' 


m_port 




integer 


m, 49170 


m number oLpcrts 




integer 


m. 2 


m transport 




varchar 


m, 'RTP/AVP* 


m fmt list 




varchar 


m. "31" 


i media title 




varchar 


i. "FoobaT 


c_networktype 






c*. M IN" 

(connection information for media) 


c_addressjype 




varchar 


c . m, P4 m 

(connection information for media) 


c_connecbon_3ddress 




varchar 


c*. "224.2.17. 12f12r 
(connection information for mecfia) 


b bandwidth 




varchar 


b*. See RFC-2327 


k method 




varchar 


k*. "dear 


k_encrypti on_key 




varchar 


k*. See RFC-2327 



r 
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6.2 Database tables for Service announcement control Information 



6.2.1 Service announcement directory (TABLE asab_control.control_info) 



Field name 


Key 


Type 


Notes 


serverjp 


X 


varchar(15) 


target server ip to which the control element refers 


server_port 


X 


integer 


target server port to which the control element refers 


Ctrl td 


X 


integer 


no duplicate control entries per server 


target_queue 




integer 


to which queue to put the SDP packets that belong to the 
scope this announcement control information 


sap_souroejp 




varchar 


IPv4 source adcTess to appear in SAP header 
See SAP specification, chapter 3 


starMime 




bigint 


Start time; when this control information activates, i,e. when 
to start announcing (in NTP) 


stopjime 




bigint 


Stop time; when this control information de-activates, i.e. 
when to stop announcing (in NTP) 


repeatjnterval 




bigint 


Announcing interval when the announcements are active, 
i.e. between startjime and stcp_time 


repeatjncrement 




Bigint 


0 = When stop Jj me reached -> delete this control entry 
<other> = When stopjime reached do the following: 
start time := stop time + repeat increment 



6.2.2 Grouped SDP table (TABLE asab_control.grouped_sdp) 



Field name 


Key 


Type 


Notes 


serverjp 


X 


integer 


target server ip to which the control element refers 


server _port 


X 


integer 


target server port to which the control element refers 


Ctrl id 


X 


integer 


no duplicate control entries per server 


sdpjd 




integer 


Reference to asab_sdp.sdp (null only in multicast listen 
case) 


refjn_dvb_param 




integer 


Reference to asabjrtapping. dvb_param (null if not used) 


ref_in_ceIl_to_ip 




integer 


Reference to asab_map pin g. eel l_toj p (null if not used) 


ref in_ip_to_cell 




integer 


Reference to asab mapping, tp to cell (null if not used) 


ref in multicast listen 




integer 


Reference to asato_control . mutti castj i ste n (null if not used) 


6.2.3 ASAB internal SAP announcements from core network (TABLE asab_control.multicastJisten) 


Field name 


Key 


Type 


Notes 


ref in multicast listen 




integer 




asab sap address 




varchar 


the ASAB internal multicast group to listen 
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6.3 Database tables for special mappings 

6.3.1 DVB parameters (TABLE asabjrnapping.dvbjparam) 



Needs asab_mapping.subcell 



Field name 


Key 


Type 


Notes 


refjn_dvto_param 


X 


integer 




c address type 




varchar 


c\ n IN4 M or"Sr 


celljd 


X 


varcriar(e) 


Examples: 

"DVB/CELLSI 34567", or, 
•DVB/CELL IN4 1*13.141 5" 


bearer 




varcfcar{8) 


* t a=bearerdvb4" 


framing 




varchar(8) 


" a=framing:dvh/mpe° 


dvb_param_1 




varchar(8) 


"a=dvb-t-bandwtdtri:8" 


dvb_param_2 




varchar(d) 


"a=dvb-t-ffi:8" 


dvb param 3 




varchar(8) 


M a=dvb-t-oonstel(ation: 1 6QAM" 


dvb param 4 




var<*iar(8) 


•^dvb-t-ooderateiM" 


dvb_param_5 




varchar(d) 


'■a=dvb4-guard-interval: 1/8" 


dvb_param_6 




varchar(8) 


"a=dvt>-t-hierarcfty:none" 


dvb_param_7 




varchar(8) 


^dyb^erarcrticaJ^omyhlgh" 



6.3.2 DVB Subcell Information (TABLE asab_mapping.subcell) 
Needs asab_mapping.dvb_param 



Field name 


Key 


Type 


Notes 


celljd 


X 


varctiar(8) 


Examples: 

"DVB/CELL SI 34587", or, 
"DVB/CELL IN4 12.13.1415' 


m medBa 




varchar(8) 


"m=nasAione" 


subceD id 


X 


integer 


M a=subcell:1 450.2/60.3N/1244E/3.1/25" 


frequency 




varchar(d) 


M a=subcell:1 450.276a3N/1244E/3.1/2.5" 


coverage^pararrM 




varchar(8) 


M a=subcell:1 450.2/60.3N/1244Ey3.1/2.5 H 


coverage _param_2 




varcfiar(8) 


H a=subcell:1 450.2/60.3N/12.44E/3.1/25 M 


coverage_param_3 




varctiar(8) 


"a=subcell:1 450.2/60.3N/1244E/3.1/2.5 M 


coverage_param_4 




varchar(8) 


"a=sUbce!l:1 450.2/60. 3N/ 12. 44 E/3. 1/2 5" 
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6.3.3 Cell to IP mapping (TABLE asab_mapping.cellJojp) 



Needs asab_mapping.xmap 



Field name 


Key 


Type 


Notes 


refjnjcelJjo_ip 


X 


integer 




sessonjgroup 


X 


integer 


reference to asab_mapping.xyz 



6.3.4 Session to cell mapping (TABLE asab_mapping.ipJo_cell) 
Needs asab^mapping.xmap 



Field name 


Key 


Type 


Notes 


refjnjp_to_cell 


X 


integer 




cell_group 


X 


integer 


ref to asab_ma pping . xyz 



6.3.5 xyz mapping (TABLE asabjnappingjcmap) 
Used by asab_mapping.cellJo_ip 
asab_mapping.ip_to_cell 



Field name 


Key 


Type 


Notes 


cell_connection_adctr_type 




varchar 


w ip4' rsr 


cell connection address 




varchar 


M .2.3.4" | ^eS" 


o user name 




varchar 


o, "-" | (user login) 


o session id 




btgint 


o ( NTP 


o_networkjtype 




varchar 


o, "IN" 


o_address_type 




varchar 


o, "INT 


o_address 




varchar 


o, (address of the machine from which the session was 
created! | (FQDN) 


sessionjgroup 




integer 




ceiljgroup 




integer 
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6.4 Database tables for server configuration 



6.4.1 Queue configuration for basic parameters (TABLE asab_oonfig.queue_config) 



Field name 


Key 


Type 


Notes 


servejp 


X 


varchar(15) 


target server ip to which the control element refers 


server_port 


X 


integer 


target server port to which the control element refers 


queue jd 


X 


integer 


identifier of the queue; not null 


target_sap_ip 




varchar 


Destination IP address in packet carrying SAP messages 
from this queue 


target_sap_port 




integer 


Target SAP port for the socket (this is for the future, if the 
queue needs to listen the annoucements itself) 


bwjimit 




integer 


the bw limit (refer to SAP specification) in bits per second. 
If this is 0, there is no limit 



7. MANAGEMENT INTERFACE 




Figure 7-1 , Overview of service&management interface operation 

7.1 Management architecture 

The management architecture bases on the the following principles: 

• Through one management unit you can access and configure arbitrary many 
announcement servers and databases. 

• Every component of the ASAB system can be managed as an independent unit. 
This allows e.g. every database to be configured independently without a 
running server (with a few exceptions, of course). 
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No components are positional. In other words the management units, 
announcement servers and databases can be located in different servers. 

Every component is functional as stand-alone unit and thus independent of the 
management unit. 

The management unit is runtime configurable in certain limits. 

Every announcement server has only one asab_config, asab_control f asab_sdp 
and asab.mapping database. Still one database can be used by multiple 
announcement servers. 
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» joonflg J 



f— 2 ^ 

I DB asab_control J 



Management Interface (CQent) 



Figure 7-2, An example of a ASAB configuration 



The management unit provides a remote management interface that you can control the 
ASAB system with. The data transfer between management unit and management 
interface is enabled by a point-to-point oonnecetion using SOAP RPC protocol. 

Connections between management unit and databases are simple SQL connections 
through Java JOBC drivers. 

AS and management unit connection protocol Is still open, but SOAP seems to be strongly 
suggested also here. 
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The server's independency of the management interface is enabled by assingning a boot 
sequence which first searches the configuration locally, second inquires it from 
management unit and is still no confdiguration is found, starts as null. 



The complete class diagram of the ASAB management inteface. Note that there's only six 
classes with services while other classes are more like data containers. 



The management interface for ASAB servers & databases One instance of tits class can be used to manage 
arbitrary many ASAB servers. Each announcement server needs four databases (asab_config, asab_control, 
asab_sdp, asab_mapping) to be able to sent announcements. Despite databases and announcement servers 
can be accessed if aO four databases are not configured. Serverldentlfler addServer(ServerC on figuration) 
Add a new server under the management . Use modifyServerConfiguration to modify a server configuration. 
Here and in the following methods in this dass the server means the complex of AS and the databases 
associated with it It's mandatory that the servers IP address & port is defined in ServerCortfiguration, although 
the defined server doesn't need to yet exist Database definition in the configuration are optional. NaturaDy the 
accessibility of databases depends on this. 

void r em oveServer(Serve (Identifier) 

Remove a server under the management Only the configuration information of the server & databases is 
removed - the action of the server and the databases is not affected. 

Vector get5ervertdentJflers() 

Get a vector of the Serverldentrfiers that are 8dded to this management interface. 

ServerConfiguration getServefConflguratlon(ServerldentJfler) 

Get the configuration of the server. 

void modifyServeiConflgurationfServeildentlfier, ServerCctiflgu ration) 

Modify the configuration of a server. 

Serverldentlfler readServerConflguraflon(Strlng, Int) 

Connect to an existing stand-alone announcement server and read its configurations. This method is similar to 
addServer, except the configurations are not given by the user of the interface but instead from a server. 
Arguments are IP adctess (String) and port (int). 

ServerAccessor getServerAccessorfServerfdentfffer) 

Get the accessor for a server. 

ConflgDbAccessor getConflgDbAccessorfServertdentlfler) 

Get the accessor for a database 3sab_conftg of a specific server. 

ControlDDAccessor getCcntrdDbAccessor(Servertdentlfier) 

Get the accessor for a database asab.corrtro) of a specific server. 



7.2 Management API 




7.2.1 <AsabManagementlnterface> 



SdpObAcoessor getSdpDbAccessort Serverldentlfler) 

Get the accessor for a database asab_sdp of a specific server. 
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MapplngDbAccessor getMapplngd)bAocessor(Servefldentffler) 

Get the accessor for a database asab_mapptng of a specific server. 

ServerCortftgura&on 
^String serverjp 
-int server_port 

-ObConftguration configDbCortfig 
-DbConftguratjon controlDbConfig 
•ObConfiguratJon sdpDbConftg 
-DbConfiguration mappingDbConfig 

ObConftguration 
-String dbDriver 
-String dbMgmtSystem 
-String dbHostlp 
-int dbPort 
-String dbNarne 
-String usemame 
-String password 



This accessor accesses the announcement server. 

Serve rState getServerStateQ 

Get the current state of the server. 

void startQueue(Queueidentlfler) 

Start a queue. 

void stopQueue(QueueJdentJfler) 
Stop a queue. 

void dlsaUeMcRecefverMappert) 

Stop listening the multicast addresses configured 

void enableMcReceJverMapperfJ 

Start listening the multicast addresses configured. The sap packet received are sent forward to queues 
configured. 

ServerState 

-Queueldentifier[] runningQueues 
-Boolean isMcReceiverMapperRunning 



In addition to their own methods, aO four database accessors ConfigDbAccessor, Control DbAccessor, 
SdpDbAccessor, MappingDb Accessor implement similar database functions, which are listed here. 

void a ppendDb(Db Accessor) 

Appends another database to this database. Appending a database to an empty database is in practice 
duplicating. This operation doesrrt affect the database which accessor is given as an argument. 

void emptyDDO 
Empty the database. 

Identifier add(Cctitent) 

Add a Content to the database. When modifying an existing Content, use modifyContent instead. As return you 
get an Identifier referring to the Content 

void rem ove(I dent! tier) 

Remove a Content from the database. 



7.2.2 <ServerAcce3sor> 



7.2.3 <Db Accessor 
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Vector getJdentffiersO 

Get a vector of tdentiers of the Contents in the database. 

Content getContent(lctentJfler) 

Get a Content element that the Identifier refers to. 

void mod IfyCon ten t(1 dentin er T Content) 

Replace the Content (in database) that Identifier refers to with Content given as argument 



Here's hew the terms above differ in different acoessors: 
DbAccessor is 

in ConfigDb Accessor. Config DbAccessor 
in ControlDbAccessor: ControlDbAccessor 
in SdpDbAccessor ScfcDb Accessor 
in MappingDbAocessor: MappingDb Accessor 

identifier is 

in ConfigDbAccessor Queueldentifter 

in ControlDbAccessor ControlEntryidentifier 

in SdpDbAccessor: SdpPacketldentifier 

in MapptngDbAccessor: 1) DvbParamldentifier, 2) CellTolpMappingtldentifier, 2) Cell Identifier 
Content is 

in ConfigDbAccessor QueueConfiguration 
in ControiDbAccessor: ControlEntry 
in SdpDbAccessor ScfcPacket 

in MapptngDbAccessor 1) DvbParam, 2) CeDTolpMapping, 3) CeO 



This DbAccessor accesses the database asab.config. 

OueueConftguraton 
-String target_sap_ip 
-int targe^_sap_port 
-int bwjimrt 



"This DbAccessor accesses the database asab_control. 

void lnsertCtilEntryfntoQueiie(CtrlEntry1dentlflej t QueueidentltJer) 

Set a control entry to a queue. The queue and control entry must have been added to the databases of the 
same announcement server before an control entry can be addressed to a queue. 

void removeCtr!EntryFromQueue(Ctr1Entryldeiitlfier l Queueldentffler) 

Remove a control entry from a queue. 

Vector getCtriEnti1es(Queue!<tentJ1]er) 

Get control entries inserted into a queue. Vector contains CtJlEntryidertftifter objects, 

Queue! den titter getTargetQueue(Cu1EntryldentJfter) 

Get queue identifier by control entry. 



void InserrroControfEntryfObfect, CtrfEntryldentlHer) 

Attach an object to aoontrol entry. The object given as can be either SdpPacketldentifier, McRecMapConfig, 
CellTotplderrtifier or DvbParam MApping 



7.2.4 <ConfigDbAccessor> 



7.2.5 <ControlDbAccessor> 
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void removeFromCcfitrciEntrytObject, CtilEntrytdentlfler) 

Remove an object from a control entry. The object given as can be either SdpPacketJdentifier, 
McRecMapConfig, CeMotpldentifier or DvbParamMapping. 

Vector geedpPaclcetldentS1Ier$(CtrtEntryfdentSfleT) 

Returns a vector of SdpPacketldentifier objects. 

Vector getMcReceiv«rMapperContlgs(Ctri Entryldentlfler) 

Returns a vector of McRecMapConfig objects. 

Vector getDvbParam Mappings (CtrtEntryldentJfler) 

Returns a vector of DvbParamMapping objects. 

Vector getCeJITofpMapplngs(Ctr1£ntryldentff1er); 
Returns a vector of CeOTolpldentjer objects. 

Vector getMcReceJverMapperCtrfEntr1es() 

Get a vector of CtrlEntrytdentifier objects that contain McReceiverMapperConfig objects. 
Vector getDvbParam MapplngCtrlEntrtes() 

Get a vector of CtrtEntryldentifier objects that contain DvbParamMapping objects. 
Vector getCeirrolpMapplngCtrtEntrlesO 

Get a vector of CtrlEntryldentjfier objects that contain CeOTolpMappingldentifier objects. 
CtrlEntry 

-String sap_source_ip 
-Jong stanV time 
-long stop_time 
-long repeatjnterval 
-long repeatjncrement 



This DbAccessor accesses the database asab_sdp. 

SdpPacket 
-int scp_type 
-String vVersion 
-String oUsemame 
-long oSessionld 
•long oVersion 
-String oAddressType 
-String o Address 
-String sSessonName 
-String information 
-String uUn 
-StringeEmafl 
-String pPhone 
-String cNetworKType 
-String cAddressType 
-String cConnectionAddress 
-String bBandwidth 

r Timings which belong into this sdp packet */ 
-Vector turnings 
-String zAdjustement 
-String kMethod 
-String kEncryptionKey 

r Session attributes which belong into this sdp packet 7 
-Vector aSessonAttrfoutes 

r Medja descriptions which belong into this sdp packet V 
-Vector mMedaDescriptions; 



7.2.6 <SdpDbAccessor> 
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MediaDe sorption 
-int meo5ald 
-String mMedta 
-intmPort 

-mt mNu mbe rOfPorts 
-String m Transport 
-String mFmtUst 
-String i Media Title 
-String cNetworkType 
-String cNetworKAddress 
-String cConnection Address 
-String bBandwidth 
-String kMethod 
-String kEncryptonKey 

TimeDescription 
-long tStartTime 
-tong tStopTime 
-long rRepeatlntervaJ 
-tong rActiveDuration 
-String rOffsets 

SessionAttribute 
-MedaDescnption medatd 
-String aName 
-String aValue 



This Ob Accessor accesses the database asab_mappirtg. 

Note: The method hierarchy in this accessor is still under development 

DvbParam Mapping addDvbParamMapp<ng() 

Generate a new DvbParam Mapping object The object is used to map DvbParams to CtriEntrys. 

void rejnoveDvtoParamMapplng(DvbPararnMappIng) 
Remove a DvbPararn Mapping. 

Vector getDvbParamMapplngs() 

Gets a vector of DvbParamMapping objects. 

DvbParamMapping is ony an unique identifier given by the database. For the time being all mapping 
datastructures must be constructed manually. 

DvbParam 

-DvbParamMapping refjn_dvb j>aram 

-Ceflldentifier ceJMd 

-String bearer 

-String framing 

-String dvb_param_1 

-String dvb _param_2 

-String dvbj>aram_3 

-String dvbj>aram"4 

-String dvb _param_5 

-String dvb_param_6 

-String cM>j>aram~7 

SubCefl 

-int suboefl_id 

-String m_me<fia 

-String frequency 

-String coverage _param_1 

-String coverage _j>aram_2 



7.2.7 <MappingDbAccessor> 
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-String coverage j>aram_3 
-String coverage _param_4 

CeiUolp 

-Ceflldentifter oeJIJd 
-DvbParamldentifier sdp_oellJd 
-String ip_ad dress 
-String ip~source 



-String c_address_tvpe 
-String eel I id; 

r A vector of SubCeO objects At least one subCell is needed. Tf 
-Vector subCelte 



Cell 
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7.3 Example case 



Configuring announcement server from the beginning to send one session 
announcement with a DVB cell paramemeter announcement included 



MySQL 



Add new 
server 



Add queue 



odtfSerwertSefvefConllgirationXSefverMenttler 



QetConfi{ptaAccesso!{Sefver1deiTt)1ierX ConHgDbAccessor new 



adtfQueue(QueueConSguratnnXOueufll4ent)ficr 



Management /DB \ 
connectivity j 
i | 
(cr&atB connection to essb^ccnfig) 

4 



I jfcc : INSERT INTO asab^config . 



-»: 



Add sdp 
packet 



j i 
getSOFObAccessoftServerfdentiller): SGjjDbAceesscr 



8ddS<lppQcJ^S<J|^ackatJS<»jPockefloentfieT 



..(create connection to asab_sdp) 

1 



J<Jbc : INSERT INTO asab,sc> ... 



9etMepp'ngDbAcc«sson;ServeTlden1if!er£ MappngDbAccesscr 



Add mapping 



aQTdCcflQrCeli ctentificr 



e^oDvtoPereinCDvtJPan3Tn) D*Parem!dentmer 



(create connection to &sab_ma£ping) < 



! 5j 

jdbc : INSERT INTO oaab_mapping ... \ 



Jdbc : INSERT INTO esab_mapptng .. 



Jtibc : INSERT INTO esatLmapping ... 



oetControJDbAc cessorfServari denf fier^ControIDbAccessoT 

i J 



■LI 



.ctri) 



Add new 
control entry & 
configure it 



adeKartErrtry(ControtEntjyfc<Xn^ 



; in»rtCWBn^ntDQtfa>»IControiEn1iYldbrtfftef. Queu eM eii li fiei) 



1 

tnssrtlntoOrtEfTtrylSdpPgokcttdBnifllBf, CtriEntrytdedBRar) 



tnaarttntoCtriEntTYtDvtoPanarnMappttQ, CtrtEntrytdenilfiss} 



Jdbo : INSERT INTO eaab_ctr1 ... 



ftlbc : UPDATE asab.coi . 

1 



-3 



jdbc : UPDATE as8b_ctrt ... 

1 i 



jdbc : UPDATE asab_cti1 ... 



getServerAc oescorXServeri dent flet£ Server Accessor 

j ?! 



SerwrAocrosor 



Start queue and 
inquire for the 
state of the server 



startQueue<Oufluefoenfitier) 



getServerSUteO ServerState 



Management / AS 
connectivity 

(start qjeue) 



(state lno>xiry) 
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PART 3 - SERVER TEST SPECIFICATION 

This part lists all the test cases for ASAB server. The tests include both component tests as 
well as functional tests. 



8. COMPONENT TESTS 



8.1 Test drivers 



For component tests, there are test drivers for each tested module/component. The tests 
belong to package nrc.asab.tests. For example class nrc.asab.server.Queue has a test 
driver nrc.asab.tests.QueueJestd river. 

The driver classes are runnable. One should use test number(s) as parameters. For 
example, the following command runs tests 5-10 for class Queue. 

java nrc. acab. le3L3.Cueue__le;;ldriver i 1C 

See the Java doc-documentation for test cases and further information. 
8.2 Testing coverage 







1 






2 






i 











9. FUNCTIONALITY TESTS 
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ANNEX A • TERMS OF REFERENCE 



This chapter defines the terms used In ASAB project. In the following definitions,. 



Announcement 

control 

information 

111 l\r t 1 I HI \m Wi 1 


Annoucement control information controls how the service descriptions 
should be announced. 


Announcement 
Server 


Server in the distribution network or in the UBA core network, which 
creates service announcements and sends those to correct cells/links. 


Service 


The words service and session are used in a mixed way 

Service is something network offers and provides to end user. Services 
can be divided into individual services which are meant for one user or 
multiparty services which are aimed to two or more users. Examples of 
individual services are for example: video-on-demand and network 
access (aka. connectivity, or bit pipes with different characteristics). 
Multiparty services can be divided to private and public services. 
Examples of multiparty services are broadcast news service, broadcast 
file distribution service, multicast of web pages, mp3 distribution by 
broadcast, etc. 


Service 

announcement 


Also called session announcement due to the close relevance to SAP. 
The service announcement is a message that contains service/session 
description. The service announcement is the vehicle to convey the 
description from announcer to potential service users. 


Service 
description 


Also called session description due to the close relevance to SDP. The 
service description defines the type of service and other parameters 
related to it. 
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ANNEX B - UML CLASS DIAGRAM OF THE SERVER 
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INSTRUCTIONS FOR COMPLETING THE INVENTION REPORT 

This Invention Report form is used in cases where an invention has been made by an 
employee of the Company. This Invention Report is confidential. Only the Patent 
Department may make copies of signed Invention Reports in order to request opinions or 
reply to the inventor(s). 

The inventor completes the Invention Report and the description of the invention. The 
inventor does not fill in the 'Invention Report received 1 field. This field is filled in by the 
Patent Department. The Invention Report must have the names of all the inventors and 
their home addresses. If there is not enough space for all the names, addresses etc, 
please write them on a separate attachment. The first mentioned inventor is assumed to 
be the contact person In matters concerning the Invention Report. In the fields of office 
address, phone and fax, please fill in the contact person's information. Fill in the project 
field, if the invention is made in a project. The original Invention Report is signed by all 
inventors. Each page of the original Invention Report is signed by a Manager. In case it 
is difficult to obtain Manager's signature your Patent Department will take care of it. 

It is suggested that the Invention Report and the description of the invention should be 
filled in as thoroughly as possible. If drawings or other kind of information cannot be 
attached to this form, they should be delivered separately. 

The signed Invention Report is given directly to the local or business unit's Patent 
Department. Invention Report should also be sent by E-mail to the Patent Department. 
The Patent Engineer will inform the inventor of receiving the Invention Report. The 
Patent Engineer will obtain any expert opinions needed to property evaluate the 
invention, will procure the Company's decision and Inform the inventor accordingly. 
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DESCRIPTION OF THE INVENTION 



1. Field and background of the invention 

The field of the invention is data networking in unidirectional access systems. More presicely the invention 
relates to digital broadcast systems capable of broadcasting datagrams and receivers capable of receiving 
those, respectively. The invention will be explained in terms of TCP/IP networking suite, but a skilled 
person knowing the area can easily generalise the main ideas to suit any form of data networking. 

The background of invention lies In two NRC projects, DRiVE and ASAB. In DRIVE we design and specify 
a so called hybrid radio network, which by definition consist of multiple, possibly administratively 
independent, standalone radio access systems. In DRiVE the main question is how to offer the end users 
multimedia services over heterogenous radio access systems transparently. Also, the goal is to make the 
service provision cost-efficient, both for end user and the network operators. The multimedia services here 
may consist of both multicast and unicast services. This Invention, however, is applicable for multicast 
services. 

In project ASAB we desing and implement session (also called service) announcement facility for a 
broadcast system. The work contains two main parts. First, there is a service announcement server. 
Second, we design extensions to Session Description Protocol to make it capable of expressing more 
than just basic IP connectivity in fixed networks. Such extended announcements describe, for example, 
physical parameters of a DVB-T cell (frequency, MAC, and other link-level parameters). In addition, the 
announcements descibe logical mappings that the user can use to find out how to reach the session he is 
interested. For example, given a multicast IP session, in which physical cells is it reachable. This mapping 
can also appear in reverse direction: given a physical cell, which multicast IP sessions are supported in 
that. This, the protocol specification work in ASAB is highly important for this invention. 

2. A summary of the invention 

The invention presents a way a (mobile) end user of a broadcast digital access system can perform cell- 
to-cell hand-over while preserving continuity of service. Here the service is assumed to be IP multicast 
session. It is easier to figure out the invention if one assumes that the multicast session is receive-only. 
However, the invention is equally applicable to multicast sessions that are not receive-only. 

In the invention, there is a (mobile) end user that tunes to a digital broadcast data bearer. First user gets 
logical mapping messages that announce a presence of a multicast session. The user joins the session 
and starts receiving it. While receiving, the continuosty received logical mapping messages keep him 
updated about contents of the neighbouring (horizontal or vertical) cells. When reception of the current 
bearer signal goes down, has errors, or fades out, the user uses the gathered logical mappings to select a 
new physical or logical cell to attach to. After this the user joins the session and starts receiving it. 

3. Describe the problem which the invention overcomes 

The problem is best explained with an example. When the user is moving he will pass a sequence of 
broadcast cell coverage areas. The user Is receiving a session in one cell that he has tuned. When the 
user goes beyond the edge of the coverage area the reception will fade out if nothing is done. Surely, 
there are cases the user would like to preserve the session continuity. 
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4. How was the problem solved earlier? 

One way is to manually search for a new bearer. 

DVB-T standards might have some simple mechanism for performing some kind of DVB-T specific hand- 
over. (For an answer please consult DVB-T specialist) 

5. How does the invention improve earlier solutions? Advantages and disadvantages of 
the invention? 

Enables end user to make more intelligent selections based on (possibly extensive) learned knowledge 
base. 

6. Drawings and brief description of the drawings 
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Figure 1 
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Figure 3 
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CellB 




ST. Datagrams of group W 



-Sessionid-1 on Cell-A and Cell-8* 



T. "Cell-A and Cdl-8 
access parameters" 




4*. Join multicast group W that 
represents Sesstonid-1 



Figure 4 



There are four figures (Figures 1 to 4) that present the sequence of events and actions that take place 
according to this invention. The following explanation details the sequence. Below, the 'user is assumed 
to be intelligent service browser or equivalent - not the actual end user of the terminal equipment. 



0. First, the user is attached to Cell-A and is receiving a logical announcemnt channel. This 
can be either predefined or dynamically configure IP multicast address. The broadcast 
network makes session announcements and mapping announcements available on this 
logical announcement channel. 

1 . User receives SDP announcement of session that has identifier Sessionid-1 . There is 
also a mapping that tells that Sessionid-1 is available in Cell-A as well as in Cell-B. 

2. User receives detailed link-level access parameters of Cell-A. 

3. User optionally retunes to Cell-A (in case of DVB-T, user might need to change the MAC 
address or PID in the receiver end) 

4. User joins the multicast group *m* that was announced to represent Sessionid-1 . Note 
that because user does not have an uplink, the join message is merely registered the 
operating system and the IP stack. However, it does not send any concrete IGMP join 
message anywhere. 

5. User starts to receive datagrams of multicast group 'm* on Cell-A 

6. While receiving group *m\ the user still receives session announcements and logical 
mappings. In this message, for example, Sessionid-1 is announced together with 
information that the Sessionid-1 is available on Cell-A as well as on Cell-B. 

7. User receives detailed link-level access parameters of Cell-B 

8. Reception of Cell-A signal may be lost for vartuos reasons. The user may have left the 
coverage area, the Cell-A transmitter may experience a malfunction, there may be 
interference from some other source, etc. 

9. User looks up the received mappings for Sessionid-1 . He finds that Sessionid-1 is 
available on Cell-B. User also looks up for Cell-B and learns the detailed link-level 
access parameters. 

3'. User tunes to Cell-B. (Note, from this point the logic follows numbering starting from 3.) 
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4'. User joins the multicast group 'rrf that was announced to represent Sessionid-1 . 



5*. User starts (continnues) to receive datagrams of multicast group W on Cell-B 

6*. While receiving group m', the user still receives session announcements and 
logical mappings. In this message, for example, Sessionid-1 is announced 
together with information that the Sessionid-1 is available on Cell-A as well as 
on Cell-B. 



7. A more detailed description of the invention (if known at the moment) 

See 6 above. 

8. Explain, how the invention is/can be implemented. Which would be the beat mode of 
implementation? 

If the announcement capability already exists the implementation will have impact to end users, only. 
There are two ways to implement. First, as operating system level function, or the as intelligent service 
browser (preferred). 

9. Explain how we can recognise if a competitor is using the same product/feature? 



10.1s it planned to use tfie invention in a Nokia product? If so, when and in which product? 
Is the invention standard related? 

NVO/NEW/IPDC and project ASAB are designing and implementing announcement server that is capable 
of performing the announcing system. That system might become a part of Nokia product by the end of 
year 2002. 

11. Abbreviations 

ASAB Advanced Service Announcement for Broadcasting 
DVB-T Digital Video Broadcast Terrestrial 
SOP Session Description Protocol 

1 2. Any further comments 
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From: Aaxnio An (NVO/Helsinki) 

To: Patent-Agency Baxmer-Witcoff (EXT-RES/Waahington) 
Cc: 

Subject: 19377 Entitled A METHOD FOR PERFORMING HANDOVER FOR MULTICAST SESSIONS IN U 

Sent: 10/1/01 6:02 PM Importance? Normal 

~ — " — — 1. 

Banner & Witcof f Ltd I / / u a Uff 

1001 G Street, N.W. 
Washington, DC 200001-4597 
USA 

01.10.2001 

Re: Intended U.S. Patent Application in the name of Nokia Corporation 
Entitled A METHOD FOR PERFORMING HANDOVER FOR MULTICAST SESSIONS IN U 
Your Ref: 
Our Ref: 19377 

Rating: 2SL,. V ... rr . ? ~, K ~ ■ : ., ?• ■ • 

; inVentbr^oni Paila, Bverstinkuja 1 c 66, 02600 ESPOO 
Jani "Poikela, Kaarikuja 4 F 125, 00940 HELSINKI 
Lin Xu, Vilppulanpolku 4 A 1, 33720 Tanjpere 
Juha-Pekka Luoma, Sammonkatu 8 C 36, 33540 TAMPERE 
Rod Walsh, Maentakusenkatu 17 A 3 33710 TAMPERE 

Brad, 

I hope you are able to draft this new application. 
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From: Patent-Agency Banner- Witcoff (EXT-RES/Washington) 

To: Aamio Ari (NVO/Helsinki) 

Cc: 

Subject: NC19377; B&W 4770.00026 - First Draft 

Sent: 10/30/01 10:06 PM 



Ari, 

Attached please find a first draft application (13 pages, inluding claims and abstract) and figures (5 additional pages, 
figures 1-7) for the above-referenced matter. Please have the inventors review the draft and provide any comments or 
changes. Specifically, please have them at least answer the questions embedded in the application in [ALL CAPS IN 
BRACKETS]. As this Application has a file-by date of November 19, 2001, PLEASE PROVIDE ANY COMMENTS 
TO US BY NOVEMBER 12, 2001 so that we will have time to prepare the revised draft and return it to you for 
approval. As always, please do not hesitate to contact us with any questions. We look forward to receiving your 
comments soon. 

Regards, 

Ross Dannenberg 

Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
Direct: (202) 508-9153 
Direct Fax: (202) 585-5908 
Main: (202) 508-9100 
Main Fax: (202) 508-9299 
rdannenberg@bannerwitcoff.com 

IMPORTANT/CONFIDENTIAL: This message contains information from the law firm of Banner & Witcoff, LTD. 
which may be privileged, confidential, or exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited. If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 

!3»22773 1. DOC 13427030 1.PDF 




Importance: Normal 
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To: 



From: 



Patent-Agency Banner- Witcofif (EXT-RES/Washington) 
Aamio Ari (NVO/Helsinki) 



Cc: 



Subject: 
Sent: 



NC19377; BW 04770.00026 - Revised Draft 
11/13/01 10:00 PM 



Importance: 



Normal 



Ari, 



Attached please find a revised draft application and drawings for the above-referenced case, as well as formal 
declaration and assignment documents. Please have the inventors review die revised draft and, assuming all is in order, 
sign and return the executed declaration and assignment documents. 

In reviewing the revised draft and accompanying papers, please note: 

1) Also attached is a separate document showing the changes made in "redline" format, to more easily demonstrate the 
revisions from the previous draft 

2) Please confirm the inventors' citizenship information in the attached declaration document, as we only received 
citizenship information for the first named inventor. Please make any necessary corrections on the attached declaration 
document 

3) Please confirm the inventors' address information. Specifically, Rod Walsh has a different address than that provided 
with a previous application on which he is a named inventor. Please make any necessary corrections on the attached 
declaration and assignment documents. 

Please let me know if you have any questions or if any other changes are required. As this application is due to be filed 
by November 19, please let us know as soon as possible if changes are required. Otherwise, we will file the application 
as soon as we receive the executed documents. Thank you for allowing us to be of assistance, and we look forward to 
hearing from you soon. 

Regards, 
Ross 

Ross Dannenberg 
Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
Direct (202)508-9153 
Direct Fax: (202) 585-5908 
Main: (202) 508-9100 
Main Fax: (202) 508-9299 
rdannenbeig@baimerwitcofif.com 

IMPORTANT/CONFIDENTIAL: This message contains information from the law firm of Banner & Witcoft LTD. 
which may be privileged, confidential, or exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited. If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 



https://192 J00J02.60/exchange/fo^ i 1/13/2001 



• NC19377; BW 04770.00026 - "^vised Draft Page 2 of 2 

l 3Application-Redlined.DOC 1 3427030 1. PDF 1 3429489 1. DOC 1 3429870 1 DOC 1 )429871 1.DOC 



https://192.100J02.60/exchange/form^ 1 1/13/2001 



02/06 04 10:00 FAX +358 7180 36060 * BANNER WITCOFF @002 




IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 



In re the Application of: 
Toni Paila et aL 
Serial No.: 09/988,241 
Filed: November 19, 2001 
For: MULTICAST SESSION HANDOVER 



Atty. Docket No.: 004770.00026 

Group Art Unit 2682 

Examiner West, Lewis G. 

Confirmation No.: 8406 



RECEIVFT 



DECLARATION UNDER 37 CJ.R. S 1.131 
The Honorable Assistant Commissioner for Patents J UN 0 7 2004 

«m*w*m.»»i Technology Center 2600 

Sir. 

Wc, Toni Paila (Finnish), Jani Poikela (Furnish), Lin Xu (Chinese), Juha-Pekka Luoma 
(Finnish), and Rod Walsh (British), hereby declare that 

1) We are the joint inventors of the above-captioned application; 

2) Prior to October 1 1, 2001, the filing date of U.S. Patent Application Publication 
US 2003/0073453 Al (hereinafter "Basilier"), >w conceived of the invention 
recited in claims 1-47 of the above-captioncd application, at least to the extent the 
claims are allegedly taught by Basilier. 

3) We prepared a disclosure document (copy attached hereto as Exhibit A) of an 
embodiment of the invention. 

4) The dates deleted from Exhibit A are prior to October 1 1, 2001. 

5) The disclosure document attached as Exhibit A was sent to our patent attorney, 
Mr. Bradley C. Wright of the law firm Banner & Whcoff, Ltd., on October 1, 
2001, as evidenced by the email communication attached as Exhibit B. 

6) On October 30, 2001 , Ross Dannenberg (also an attorney with Banner & Witcoff, 
Ltd.) sent a draft of the above<aptdoned patent application to our employer for 
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our review* A copy of the email communicating the draft is attached as Exhibit 
C, 

7) On November 13, 2001 Ross Daimenberg sent a revised draft of the above- 
capdoned patent application. A copy of the email communicating the revised 
draft is attached as Exhibit D. 

8) On November 19, 2001, the above-captioned patent application was filed in the 
U.S. Patent and Trademark Office. 

9) The exchange of draft applications with our patent attorney demonstrates 
diligence from before October 1 1, 2001 until the filing of the above-captioned 
patent application and the constructive reduction to practice of our invention. 

10) All acts referred to in this Declaration were performed either in the United Stales, 
or in a WTO member country, as evidenced by submitting an Invention Report to 
our employer's internal Patent Committee on a date prior to October 1 1 , 200 1 ; 

1 1) The attached Exhibits have not been altered since they were originally submitted 
to the Patent Committee or otherwise prepared or communicated; and 

12) We declare under penalty of perjury under the law of the United States of 
America that statements made herein of our own knowledge are true and that all 
statements made on information and belief are believed to be hue; and further that 
these statements were made with the knowledge that willful false statements and 
the like so made are punishable by fine or imprisonment, or both, under Section 
1001 of Tide 18 of the United States Code and that such willful false statements 
may j eopardize the validity of the application or any patent issuing thereon. 

SIGNATURES BEGIN ON NEXT PAGE 
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Respectfully submitted, 



ToniPaila r\ a Date 





Lin Xu Date 



Date ^ 



Juha^ekka Luoma Dale 

2| M«w 2co^ 



Rod WaLsh Date 



Decteraiion Under 37 C.F.R § 1.131 



NOKIA 



INVENTION REPORT 



Title of invention: 

A method for performing handover for multicast session in 
uni-directional access system. 



THE DESCRIPTION OF THE INVENTION 
MUST BE ATTACHED 



INVENTION REPORT RECEIVED 



Code: 19377 



Patent Committee: 
NVO/NRC 



.Place: Helsinki 



Date: 



Signature: 



Inventor's name, employee number, title and 
nationality: *) 

Toni Paila, 10000517, Research Engineer, 
Finnish 



Home Address: *) 

Everstinkuja 1 c 66 
02600 Espoo 
Finland 



Business Unit and cost 
centre: 

NRC 1007950 



Line Manager(s): Kari A. Rissanen 



Project :*)ASAB 



Project Manager: Toni Paila 



Office address: *) NRC Ruoholahti A427 



Phone: *) +358718037389 



Fax: *) +358718036856 



The invention becomes public on: 



/ am/ We are the sole/ and original inventorfs) of this invention. 

The company may, by virtue of applicable legislation, be entitled to full or partial rights to the invention. 

1/ We acknowledge my/ our obligation to sign as inventor(s) all documents that may be required for protecting the 

invention in different countries. 

Applicable to inventions made by Inventors employed In Fl, DK, DE and SE only. 
Unless the inventor requests the Invention Report to be responded to within four (4) months from the date this 
Invention Report is received or such other period as the mandatory provisions of the applicable local law may 
otherwise require, the inventor consents to the right of the employer to use a reasonable period of time for the 
evaluation of the invention. A reasonable period of time may exceed four (4) months. 
If We request that the Invention Report be responded to within four (4) months. 

Date: 

Signature(s) of lnventor(s): 



*) See the instructions 



/ have read and understood the invention described in this Invention Report 
Date: 
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INSTRUCTIONS FOR COMPLETING THE INVENTION REPORT 

This Invention Report form is used in cases where an invention has been made by an 
employee of the Company. This Invention Report is confidential. Only the Patent 
Department may make copies of signed Invention Reports in order to request opinions or 
reply to the inventors). 

The inventor completes the Invention Report and the description of the invention. The 
inventor does not fill in the Invention Report received' field. This field is filled in by the 
Patent Department. The Invention Report must have the names of all the inventors and 
their home addresses. If there is not enough space for all the names, addresses etc, 
please write them on a separate attachment. The first mentioned inventor is assumed to 
be the contact person in matters concerning the Invention Report. In the fields of office 
address, phone and fax, please fill in the contact person's information. Fill in the project 
field, if the invention is made in a project. The original Invention Report is signed by all 
inventors. Each page of the original Invention Report is signed by a Manager. In case it 
is difficult to obtain Manager's signature your Patent Department will take care of it. 

It is suggested that the Invention Report and the description of the invention should be 
filled in as thoroughly as possible. If drawings or other kind of information cannot be 
attached to this form, they should be delivered separately. 

The signed Invention Report is given directly to the local or business unit's Patent 
Department. Invention Report should also be sent by E-mail to the Patent Department. 
The Patent Engineer will inform the inventor of receiving the Invention Report. The 
Patent Engineer will obtain any expert opinions needed to properly evaluate the 
invention, will procure the Compan/s decision and inform the inventor accordingly. 
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DESCRIPTION OF THE INVENTION 



1 . Field and background of the invention 

The field of the invention is data networking in unidirectional access systems. More presicely the invention 
relates to digital broadcast systems capable of broadcasting datagrams and receivers capable of receiving 
those, respectively. The invention will be explained in terms of TCP/IP networking suite, but a skilled 
person knowing the area can easily generalise the main ideas to suit any form of data networking. 

The background of invention lies in two NRC projects, DRiVE and ASAB. In DRiVE we design and specify 
a so called hybrid radio network, which by definition consist of multiple, possibly administratively 
independent, standalone radio access systems. In DRiVE the main question is how to offer the end users 
multimedia services over heterogenous radio access systems transparently. Also, the goal is to make the 
service provision cost-efficient, both for end user and the network operators. The multimedia services here 
may consist of both multicast and unicast services. This invention, however, is applicable for multicast 
services. 

In project ASAB we desing and implement session (also called service) announcement facility for a 
broadcast system. The work contains two main parts. First, there is a service announcement server. 
Second, we design extensions to Session Description Protocol to make it capable of expressing more 
than just basic IP connectivity in fixed networks. Such extended announcements describe, for example, 
physical parameters of a DVB-T cell (frequency, MAC, and other link-level parameters). In addition, the 
announcements descibe logical mappings that the user can use to find out how to reach the session he is 
interested. For example, given a multicast IP session, in which physical cells is it reachable. This mapping 
can also appear in reverse direction: given a physical cell, which multicast IP sessions are supported in 
that. This, the protocol specification work in ASAB is highly important for this invention. 

2. A summary of the invention 

The invention presents a way a (mobile) end user of a broadcast digital access system can perform cell- 
to-cell hand-over while preserving continuity of service. Here the service is assumed to be IP multicast 
session. It is easier to figure out the invention if one assumes that the multicast session is receive-only. 
However, the invention is equally applicable to multicast sessions that are not receive-only. 

In the invention, there is a (mobile) end user that tunes to a digital broadcast data bearer. First user gets 
logical mapping messages that announce a presence of a multicast session. The user joins the session 
and starts receiving it. While receiving, the continuosly received logical mapping messages keep him 
updated about contents of the neighbouring (horizontal or vertical) cells. When reception of the current 
bearer signal goes down, has errors, or fades out, the user uses the gathered logical mappings to select a 
new physical or logical cell to attach to. After this the user joins the session and starts receiving it. 

3. Describe the problem which the invention overcomes 

The problem is best explained with an example. When the user is moving he will pass a sequence of 
broadcast cell coverage areas. The user is receiving a session in one cell that he has tuned. When the 
user goes beyond the edge of the coverage area the reception will fade out if nothing is done. Surely, 
there are cases the user would like to preserve the session continuity. 



/ have read and understood the invention described in this Invention Report 
Date: 
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One way is to manually search for a new bearer. 

DVB-T standards might have some simple mechanism for performing some kind of DVB-T specific hand- 
over. (For an answer: please consult DVB-T specialist) 

5. How does the invention improve earlier solutions? Advantages and disadvantages of 
the invention? 

Enables end user to make more intelligent selections based on (possibly extensive) learned knowledge 
base. 

6. Drawings and brief description of the drawings 




1."Sessionid-1 on Cell-A" 



2. "Cell-A parameters" 




3. (Optionally) Retune to the Cell-A 



4. Join multicast group 'm* that 
represents Session id- 1 



Figure 1 




5. Datagrams of group W 



6. "SessionkJ-1 on Cell-A and Cetl-B 



7. "Cell-B access parameters" 



it I 

User 



Figure 2 




User 9- Look up mappings for Sesstonid-1 
' -> found Cell-B + its parameters 



Figure 3 
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Cell A 



^5 



CellB 



5'. Datagrams of group 'm' 



6'. 'Sessionid-1 on Celi-A and Cell-8" 



7\ "CeH-A and Cell-B 
access parameters" 




[User *v 4 '- J« n multicast group *m' that 
— ■r 1 -' ) represents Sessionid-1 



Figure 4 



There are four figures (Figures 1 to 4) that present the sequence of events and actions that take place 
according to this invention. The following explanation details the sequence. Below, the 'user* is assumed 
to be intelligent service browser or equivalent - not the actual end user of the terminal equipment. 



0. First, the user is attached to Cell-A and is receiving a logical announcemnt channel. This 
can be either predefined or dynamically configure IP multicast address. The broadcast 
network makes session announcements and mapping announcements available on this 
logical announcement channel. 

1 . User receives SDP announcement of session that has identifier Sessionid-1 . There is 
also a mapping that tells that Sessionid-1 is available in Cell-A as well as in Cell-B. 

2. User receives detailed link-level access parameters of Cell-A. 

3. User optionally retunes to Cell-A (in case of DVB-T, user might need to change the MAC 
address or PID in the receiver end) 

4. User joins the multicast group 'm' that was announced to represent Sessionid-1 . Note 
that because user does not have an uplink, the join message is merely registered the 
operating system and the IP stack. However, it does not send any concrete IGMP join 
message anywhere. 

5. User starts to receive datagrams of multicast group 'nV on Cell-A 

6. While receiving group *m\ the user still receives session announcements and logical 
mappings. In this message, for example, Sessionid-1 is announced together with 
information that the Sessionid-1 is available on Cell-A as well as on Cell-B. 

7. User receives detailed link-level access parameters of Cell-B 

8. Reception of Cell-A signal may be lost for variuos reasons. The user may have left the 
coverage area, the Cell-A transmitter may experience a malfunction, there may be 
interference from some other source, etc. 

9. User looks up the received mappings for Sessionid-1 . He finds that Sessionid-1 is 
available on Cell-B. User also looks up for Cell-B and learns the detailed link-level 
access parameters. 

3\ User tunes to Cell-B. (Note, from this point the logic follows numbering starting from 3.) 
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4\ User joins the multicast group *m' that was announced to represent Sessionid-1 . 

5*. User starts (continnues) to receive datagrams of multicast group W on Cell-B 

6'. While receiving group 'm' ( the user still receives session announcements and 
logical mappings. In this message, for example, Sessionid-1 is announced 
together with information that the Sessionid-1 is available on Cell-A as well as 
on Cell-B. 

7. A more detailed description of the invention (if known at the moment) 

See 6 above. 

8. Explain, how the invention is/can be implemented. Which would be the best mode of 
implementation? 

If the announcement capability already exists the implementation will have impact to end users, only. 
There are two ways to implement. First, as operating system level function, or the as intelligent service 
browser (preferred). 

9. Explain how we can recognise if a competitor is using the same product/feature? 



10.1s it planned to use the invention in a Nokia product? If so, when and in which product? 
Is the invention standard related? 

NVO/NEW/IPDC and project ASAB are designing and implementing announcement server that is capable 
of performing the announcing system. That system might become a part of Nokia product by the end of 
year 2002. 

11. Abbreviations 

ASAB Advanced Service Announcement for Broadcasting 
DVB-T Digital Video Broadcast Terrestrial 
SDP Session Description Protocol 

12. Any further comments 
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From: Aarnio An (NVO/Helsmki) 

To: Patent-Agency Banner-WitcofF (EXT-RES/Washington) 
Cc: 

Subject: 19377 Entitled A METHOD FOR PERFORMING HANDOVER FOR MULTICAST SESSIONS IN U 

Sent: 10/1/01 6:02 PM Importance? Normal 




Jc 



Banner & Witcoff Ltd 



1001 G Street, N.W. ^ V / \H 

Washington, DC 200001-4597 * ^ 



USA 



01.10.2001 

Re: Intended U.S. Patent Application in the name of Nokia Corporation 
Entitled A METHOD FOR PERFORMING HANDOVER FOR MULTICAST SESSIONS IN U 
Your Ref: 
Our Ref: 19377 

Rat ing : 2S r , ■ v . -cv-.w • :. :. ■ ...*-.' 

InVehtoi;: ; Toni Paila, Everstinkuja 1 c 66, 02600 ESPOO 
Jani "'feikela, Kaarikuja 4 F 125, 00940 HELSINKI 
Lin Xu, Vilppulanpolku 4 A 1, 33720 Tampere -i 
Juha-Pekka Luoma, Sammonkatu 8 C 36, 33540 TAMPERE ? 
Rod Walsh, Maentakusenkatu 17 A 3 33710 TAMPERE ,; 

Brad, 

I hope you are able to draft this new application. 
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To: 



From: 



Patent- Agency Banner- Witcoff (EXT-RES/Washington) 
Aamio Ari (NVO/Helsinki) 



Cc: 



Subject: 
Sent: 



NC19377; B&W 4770.00026 - First Draft 
10/30/01 10:06 PM 



Importance: 



Normal. 



Ari, 



Attached please find a first draft application (13 pages, inhiding claims and abstract) and figures (5 additional pages, 
figures 1-7) for the above-referenced matter. Please have the inventors review the draft and provide any comments or 
changes. Specifically, please have them at least answer the questions embedded in the application in [ALL CAPS IN 
BRACKETS]. As this Application has a file-by date of November 19, 2001, PLEASE PROVIDE ANY COMMENTS 
TO US BY NOVEMBER 12, 2001 so that we will have time to prepare the revised draft and return it to you for 
approval. As always, please do not hesitate to contact us with any questions. We look forward to receiving your 
comments soon. 

Regards, 

Ross Dannenberg 

Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
Direct: (202) 508-9153 
Direct Fax: (202) 585-5908 
Main: (202) 508-9100 
Main Fax: (202) 508-9299 
rdarmenberg@bannerwitcoff.com 

IMPORTANT/CONFIDENTIAL: This message contains information from the law firm of Banner & Witcoff, LTD. 
which may be privileged, confidential, or exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 
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From; 



Patent-Agency Banner- Witcoff (EXT-RESAVashington) 
Aamio An (NVO/Helsinki) 



Cc: 



Subject: 
Sent: 



NC19377; BW 04770.00026 - Revised Draft 
11/13/01 10:00 PM 



Importance: 



Normal 



An, 

Attached please find a revised draft application and drawings for the above-referenced case, as well as formal 
declaration and assignment documents. Please have the inventors review the revised draft and, assuming all is in order, 
sign and return the executed declaration and assignment documents. 

In reviewing the revised draft and accompanying papers, please note: 

1) Also attached is a separate document showing the changes made in "recline" format, to more easily demonstrate the 
revisions from the previous draft 

2) Please confirm the inventors' citizenship information in the attached declaration document, as we only received 
citizenship information for the first named inventor. Please make any necessary corrections on the attached declaration 
document 

3) Please confirm the inventors 1 address information. Specifically, Rod Walsh has a different address than that provided 
with a previous application on which he is a named inventor. Please make any necessary corrections on the attached 
declaration and assignment documents. 

Please let me know if you have any questions or if any other changes are required. As this application is due to be filed 
by November 19, please let us know as soon as possible if changes are required. Otherwise, we will file the application 
as soon as we receive the executed documents. Thank you for allowing us to be of assistance, and we look forward to 
hearing from you soon. 

Regards, 
Ross 

Ross Dannenberg 
Banner & Witcoff, Ltd 
1001 G Street, NW 
Washington, DC 20001-4597 
Direct: (202) 508-9153 
Direct Fax: (202) 585-5908 
Main: (202) 508-9100 
Main Fax: (202) 508-9299 
rdannenberg@barmerwitcofT.com 

IMPORTAOT/CONFIDENTIAL: This message contains information from the law firm of Banner & Witcofi; LTD. 
which may be privileged, confidential, or exempt from disclosure under applicable law. If the reader of this message is 
not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, you 
are hereby notified that any dissemination, distribution, retention, archiving, or copying of the communication is strictly 
prohibited. If you have received this communication in error, please notify us immediately by return e-mail, telephone, 
or facsimile. 
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